apt не взаимодействует и не должен взаимодействовать я языками, единственное его дело контролировать зависимости, устанавливать/удалять/обновлять. Если бы ПМ под каждый недоязык подтачивались мир бы дано рухнул, а если языку нужно что бы под него поддержка впиливалась какая то на уровне системы...неужели в расте всё так плохо что для него какието особые условия нужны и иначе он может только сам в себе жить со своим ПМ которых с годами станет как ягод на дереве рябины?

Зачем вы в систему тащите всякую гадость в обход ПМ? У вас там Слака?

Я и не тащу, nixos запрещает. Но в этом вся моя мысль - несколько ПМ => возможность ставить гадость в обход единственно верного ПМ => потенциальная помойка.

через conda «в пользователя», ... через pip «в пользователя». Это - ад.

Потому что понаставят фигни, которую ПМ «выше» не видит, и на каждом слое у них целостная картина зависимостей, а после всех затенений (и одного апдейта) - минное поле.

Один и тот же пакет на Debian Buster с Anaconda можно поставить через apt «в систему», через conda «в систему», через conda «в пользователя», через pip «в систему», через pip «в пользователя». Это - ад.

Три каких ПМ?

см. на что отвечаешь.

Например, как взаимодействуют cargo и apt/dpkg?

Врать не буду, не знаю, но судя по отсутствию возможности указать cargo, где брать зависимости - отвратительно.

Спроектируй и реализуй поддержку Rust в apt.

В Job.

Я пытался «просто» скормить cargo уже собранные зависимости, не вышло. Почитал, как это сделали в nixos до меня, сделали это выкидыванием cargo.

И каким образом отсутствие cargo этому поможет?

Слой кода, отвечающий за сборку с внешними зависимостями, не был бы гвоздями прибит к импотентному и некооперирующемуся cargo. Сейчас или сам вызывай rustc, или пересобирай мир по правилам cargo, среднего не дано.

ЯННП.

Я и не тащу, nixos запрещает. Но в этом вся моя мысль - несколько ПМ => возможность ставить гадость в обход единственно верного ПМ => потенциальная помойка.

Ну так не ставьте.

Потому что понаставят фигни, которую ПМ «выше» не видит, и на каждом слое у них целостная картина зависимостей, а после всех затенений (и одного апдейта) - минное поле.

Потому что вы неправильно пользуетесь прикладным ПМ. Он должен не затенять, а полностью переопределять и реализацию языка, и всё пространство имён пакетов.

Вот пример:

$  rvm list known
# MRI Rubies
[ruby-]1.8.6[-p420]
[ruby-]1.8.7[-head] # security released on head
[ruby-]1.9.1[-p431]
[ruby-]1.9.2[-p330]
[ruby-]1.9.3[-p551]
[ruby-]2.0.0[-p648]
[ruby-]2.1[.10]
[ruby-]2.2[.6]
[ruby-]2.3[.3]
[ruby-]2.4[.0-rc1]
ruby-head

# for forks use: rvm install ruby-head-<name> --url https://github.com/github/ruby.git --branch 2.2

# JRuby
jruby-1.6[.8]
jruby-1.7[.26]
jruby[-9.1.6.0]
jruby-head

# Rubinius
rbx-1[.4.3]
rbx-2.3[.0]
rbx-2.4[.1]
rbx-2[.5.8]
rbx[-3.69]
rbx-head

# Opal
opal

# Minimalistic ruby implementation - ISO 30170:2012
mruby-1.0.0
mruby-1.1.0
mruby-1[.2.0]
mruby[-head]

# Ruby Enterprise Edition
ree-1.8.6
ree[-1.8.7][-2012.02]

# Topaz
topaz

# MagLev
maglev[-head]
maglev-1.0.0

# Mac OS X Snow Leopard Or Newer
macruby-0.10
macruby-0.11
macruby[-0.12]
macruby-nightly
macruby-head

# IronRuby
ironruby[-1.1.3]
ironruby-head

Все эти версии можно ставить параллельно (или создать собственные), и они никак не будут влиять друг на друга. И в них поставить все нужные пакеты нужных версий в рамках необходимого стека.

А системный стек - для системных приложений.

Спроектируй и реализуй поддержку Rust в apt.

В Job.

Но мне это не надо. Это ты ноешь об отсутствии кооперации между cargo и системного ПМ.

При сборке каждой зависимости, требующей либ не из растомира нужно плакать и руками сочетать два ПМ.

И каким образом отсутствие cargo этому поможет?

Слой кода, отвечающий за сборку с внешними зависимостями, не был бы гвоздями прибит к импотентному и некооперирующемуся cargo. Сейчас или сам вызывай rustc, или пересобирай мир по правилам cargo, среднего не дано.

Проведи мысленный эксперимент: представь, что cargo не существует - каким образом это облегчит «сборку с внешними зависимостями» или какую там задачу ты пытаешься решить?

Ну так не ставьте.

Ну так и не нужен тогда этот язык-специфичный ПМ.

Потому что вы неправильно пользуетесь прикладным ПМ. Он должен не затенять, а полностью переопределять и реализацию языка, и всё пространство имён пакетов.

Это свойство ценно только в случаях, когда системный ПМ убог и неспособен поставить несколько реализаций языка и пространств имен пакетов одновременно. Это как вкладки в браузере - костыльное следствие импотенции window management'а и не более того.

Нужен один ПМ, который умеет в окружения, изоляцию, пользовательские профили и знает про абсолютно весь софт в системе.

Это ты ноешь об отсутствии кооперации между cargo и системного ПМ.

И мне это в apt не надо. Я ною про nixos. А там эта проблема уже решена, однако не в пользу дурацкого cargo.

Проведи мысленный эксперимент: представь, что cargo не существует - каким образом это облегчит «сборку с внешними зависимостями» или какую там задачу ты пытаешься решить?

Нет такого сценария. Ниша в экосистеме пустеть не будет, что-то да будет выполнять эти две роли. Было бы круто, если это был бы не монолитный cargo.

Ада всегда была многословной. Код на растишке будет по-короче.

Я пытался «просто» скормить cargo уже собранные зависимости, не вышло. Почитал, как это сделали в nixos до меня, сделали это выкидыванием cargo

Такой хак не будет работать? https://www.reddit.com/r/rust/comments/64hlfa/how_to_compile_a_crate_as_dynam...

Ну так и не нужен тогда этот язык-специфичный ПМ.

Нужен.

Это свойство ценно только в случаях, когда системный ПМ убог и неспособен поставить несколько реализаций языка и пространств имен пакетов одновременно.

С какой стати приложение, разворачиваемое на локалхосте под конкретную задачу, должно зависеть от системного ПМ? Локалхост вообще может оказаться в реальности докер-контейнером с голой базовой системой и без ПМ.

Вам еще не пришла в голову идея заменить утилиту make на ПМ? Это в духе вашего предложения.

Нужен один ПМ, который умеет в окружения, изоляцию, пользовательские профили и знает про абсолютно весь софт в системе.

У меня /builds/ служит симлинком на $HOME/my/projects/builds/ , в котором лежит куча скомпилированного добра, начиная от пропатченных под одну конкретную задачу утилит, до софта, который я разрабатываю и отлаживаю прямо сейчас. Про этот каталог тоже ПМ должен знать?

Это ты ноешь об отсутствии кооперации между cargo и системного ПМ.

И мне это в apt не надо. Я ною про nixos. А там эта проблема уже решена

То есть ты ноешь ради нытья. Окей.

Может и будет, но проблема не с этой стороны. Проблема в том, чтобы ее потом скормить при сборке другого крейта. Неуемную пакетно-менеджментную часть cargo не остановить, она все равно пытается полезть в сеть и пытается сделать все-все-все сама. Набор флагов, его урезонивающий, пригоден для пересборки проекта в самолете со старым Cargo.toml и валидным кешем, но никак не для сборки в чистом окружении с известными путями зависимостей.

Набор флагов, его урезонивающий, пригоден для пересборки проекта в самолете со старым Cargo.toml и валидным кешем, но никак не для сборки в чистом окружении с известными путями зависимостей.

Напиши патч.

Я ною ради выявления мирового идиотизма зоопарка ПМ вообще и cargo в частности. Если «Лучший менеджер зависимостей» проще выкинуть по самый rustc, то это былинный отказ.

Когда-нибудь я вырасту и напишу.

Но, я надеюсь, ты услышал, что в моем идеальном мире патч нужен не на cargo. Патч нужен на дурацкую идею, что каждый язык должен иметь свой, по особенному импотентный ПМ.

https://www.debian.org/security/

Это один дистрибутив. С другой стороны, в Arch или Gentoo в основном ванильный софт.

Ты не ответил про скрипт.

Конечно это сделает скрипт! Какие вопросы, чувак?

Я ною ради выявления мирового идиотизма зоопарка ПМ вообще и cargo в частности

Было бы прекрасно, если бы был единый хороший ПМ для всего. И единая ОС. И чтобы это был Debian Linux.

К сожалению, это невозможно. Хнык-хнык.

Нужен.

Ну и накой? В ногу себе стрелять?

С какой стати приложение, разворачиваемое на локалхосте под конкретную задачу, должно зависеть от системного ПМ? Локалхост вообще может оказаться в реальности докер-контейнером с голой базовой системой и без ПМ.

С той, что лучше зависеть от системого ПМ, чем от его брата-импотента из поставки языка.

Вам еще не пришла в голову идея заменить утилиту make на ПМ? Это в духе вашего предложения.

Не язви, гранулярность не та.

У меня /builds/ служит симлинком на $HOME/my/projects/builds/ , в котором лежит куча скомпилированного добра, начиная от пропатченных под одну конкретную задачу утилит, до софта, который я разрабатываю и отлаживаю прямо сейчас. Про этот каталог тоже ПМ должен знать?

Да, именно! Как только они перестают быть листьями дерева зависимостей и становятся кому-то нужны, в дело должен вступить ПМ.

Почитай, если интересно, какая философия у Nix. Там как раз вся эта шелуха с виртуальными окружениями, изоляцией «параллельно установленных» пакетов и насильным использованием единого ПМ для всего-всего сделана максимально правильно, аж забрызгивает максимализмом.

Это один дистрибутив.

Такой - не один.

С другой стороны, в Arch или Gentoo в основном ванильный софт.

В Gentoo тоже фиксят дыры. А вот Арч - он один такой.

Ты не ответил про скрипт.

Конечно это сделает скрипт! Какие вопросы, чувак?

Больше никаких, чувак!

Даже интересно, тут много людей, которые знают оба языка и смогут конструктивно ответить на вопрос в ОП?

Да, было бы здорово. Да, к сожалению apt принципиально очень примитивен в этом плане.

Айда на NixOS! Единой системой она вряд ли станет, но как прототип самого правильного в мире ПМ очень даже годна. Надеюсь ПМ будущего научатся у Nix хоть половине его годноты.

Айда на NixOS!

Уже год как собираюсь попробовать Nix (пакетный менеджер, не ОС). Руки никак не доходят.

А вот Арч - он один такой.

Да нет, не один. Дистрибутивов с ванильным софтом довольно много.

Я сейчас пробежался по nixpkgs. Там меньше 2000 патчей в сумме, все или почти все правят сборку (пути, зависимости и т.д.). Правкой кода, закрытием дыр и бэкпортом фич занимаются разве что Debian и Red Hat, а также производные дистрибутивы. Остальным проще новую версию опакетить.

Правкой кода, закрытием дыр и бэкпортом фич занимаются разве что Debian и Red Hat, а также производные дистрибутивы.

...а так же Gentoo и SUSE. Все вместе они составляют... примерно 146% Linux-машин. Но ты можешь ориентироваться на Arch и Nix.

О да, большая проблема.

Вообще-то, большая.

http://www.opennet.ru/opennews/art.shtml?num=49490

и про leftpad ты забыл уже, наверное?

Если тебе нужна конкретная версия, ты можешь указать ее. Если ты этого не делаешь, ты некомпетентен и тебе невозможно помочь.

Про компетентность лучше помалкивай, пока тебя лицом в твою не ткнули.

Конкретная версия мне не нужна, поскольку это конкретные непофикшенные баги и уязвимости.

Обновлять версию руками мне тоже не нужно, потому что моё, как разработчика, время слишком дорого.

Самообновляющаяся на неизвестно что версия мне тоже не нужна.

Что же делать? А то что делаем 20 уже лет - есть репозиторий и специально обученные люди, обновляющие там пакеты следя чтобы ничего не сломалось.

Ну, попробуй подмени версию на crates.io.

Если это ты так попытался что-то из сказанного мной опровергнуть, поздравляю - ты не дружишь с логикой.

и про leftpad ты забыл уже, наверное?

leftpad - это следствие некомпетентности разработчиков на JS и ошибки дизайна npm. От этого невозможно защититься.

Про компетентность лучше помалкивай, пока тебя лицом в твою не ткнули.

Ткни, какие проблемы.

Конкретная версия мне не нужна, поскольку это конкретные непофикшенные баги и уязвимости.

Тогда не жалуйся.

Ну, попробуй подмени версию на crates.io.

Если это ты так попытался что-то из сказанного мной опровергнуть

Это я так сказал (не попытался, а сказал), что ты не привел ровно никаких доказательств или хотя бы доводов.

Ну и накой? В ногу себе стрелять?

Стрелять в девелоперскую машину, в тестеров и в продакшен из одного ружья.

Не язви, гранулярность не та.

Вот она и в обсуждаемой задаче не та, а ты всё равно хочешь натянуть сову на глобус. Что делать?

С той, что лучше зависеть от системого ПМ

Несуществующего?

Да, именно! Как только они перестают быть листьями дерева зависимостей и становятся кому-то нужны, в дело должен вступить ПМ.

Они нужны мне. И мне они в системе не нужны.

Почитай, если интересно, какая философия у Nix.

Я знаю, как устроен Nix.

Но, я надеюсь, ты услышал, что в моем идеальном мире патч нужен не на cargo. Патч нужен на дурацкую идею, что каждый язык должен иметь свой, по особенному импотентный ПМ.

И вообще много по своему особенных языков - это бардак. Язык должен быть один.

Чем Раст лучше Ада?

Rust можно использовать для white-box cryptography даже распространяя в исходных кодах.

Это ж нифига себе ты подкинул задачку мейнтейнерам дистров. Опакетить все rust либы из интернета

Во-первых, задачку подкинул не я - это объективная необходимость.

Во-вторых, всё совершенно не надо, тем более из интернета. crates.io обречён превратиться в такую ще помойку как cpan, pypi, gems и всё что было до него, реально использоваться оттуда будут проценты пакетов, их и нужно будет, точнее придётся, опакетить.

В-третьих, ничего нового в этом нет, так делали всегда,

• https://repology.org/metapackages/python:/
• https://repology.org/metapackages/perl:/
• https://repology.org/metapackages/ruby:/
• https://repology.org/metapackages/haskell:/
• https://repology.org/metapackages/ocaml:/

и делать будут, потому что по другому никак.

И, внимание, уже делают:

https://repology.org/metapackages/rust:/

leftpad - это следствие некомпетентности разработчиков на JS и ошибки дизайна npm. От этого невозможно защититься.

Да нет, это следствие использование обособленного немодерируемого репозитория. В crates.io возможно если не внезапное удаление автором любого своего crate, то любое другое западло включая неисправленные уязвимости и полностью сломанные пакеты. И всё это вылезет когда кто-то захочет таки обновиться. И даже патч некуда будет добавить.

Тогда не жалуйся.

Мне не на что жаловаться, я сломанными пакетными системами не пользуюсь. Но кто-то может в это наступить, а кто-то намеренно замалчивает проблемы, так что молчать я не собираюсь.

что ты не привел ровно никаких доказательств или хотя бы доводов.

Целая пачка, которую ты не удосужился даже процитировать.

Ну и накой? В ногу себе стрелять?

Стрелять в девелоперскую машину, в тестеров и в продакшен из одного ружья.

Так себе оправдание для N ружей.

Несуществующего?

Существующего. Вообще не слушаешь?

И мне они в системе не нужны.

Я знаю, как устроен Nix.

Тогда ты знаешь, что там нет «в системе».

Тогда ты знаешь, что там нет «в системе».

Ложки нет.

leftpad - это следствие некомпетентности разработчиков на JS и ошибки дизайна npm. От этого невозможно защититься.

Да нет, это следствие использование обособленного немодерируемого репозитория.

Да нет, это следствие использования неподконтрольного репозитория для сборки ответственных приложений. Тем более непростительное, учитывая, что npm позволяет создавать локальные зеркала. cargo этого, кстати, не позволяет пока, но это технический недостаток, а не принципиальный.

Чем Раст.

Должен.

Что ещё за бред про системный ПМ который ставит либы для хруста, лол. Там кто-то запостил мега-профитную либу, а ты тут ждёшь такой на сервере или где-то, на говне мамонта-дебиане, вот вот, сейчас, ещё 2.5 года до нового релиза.

И ещё 100500 говнодистров заментейнить на все библиотеки хруста, рили?

Даже интересно, тут много людей, которые знают оба языка и смогут конструктивно ответить на вопрос в ОП?

в аде есть доказываине корректности, в расте нет. Вообще не понимаю, почему раст советуют как более хороший язык.

а зачем?

они уже за пакетные менеджеры срутся

сам спросил — сам ответил

здесь, как минимум, никто не знает аду.

а хуже она как раз тем, что у неё нет своего пакетного менеджера со 100500 пакетов a-la leftpad.

сегодня мы живём в мире прототипов, которые волевым решением были выкачены в продакшн.

никто не знает аду.

рокет сайнс

скорее, неуловимый джо

никто, кроме военных, сегодня не будет платить столько за разработку

Нет, конечно. Значит это должен быть ПМ, опакечивающий растовые либы в одну команду, че.

Хватит тут со своими представлениями об импотентных ПМ рассказывать, что ПМ должен, а что нет. Должен, а то, что он этого не делает - досадное недоразумение, идеальной картины мира не меняющее.

В отличие от рубей и питонов пакеты в систему не ставятся. Это ПМ для сборки, все растопакеты линкуются статически.

В расте есть модель менеджмента памяти, которой нет в аде. В т.ч. гарантия memory safety и отсутствие гонок данных в многопоточных приложениях. ИМХО, на практике это намного профитнее пресловутых контрактов ады. Контракты, если так хочется, можно и руками написать, а модель владения и заимствований — не так просто. В GLib написали для сишки, но лишь на уровне конвенции, следить за соблюдением все равно программисту.

Но с bsd ports он лучше.

Чем Ада.

ЛОРчую адеквата!

И вот почему: https://geodoo.work/night-remember-npm-total-meltdown/

Как так, модель управления памятью есть, а модели памяти нет?

А в Аде есть модель памяти?

Ада - высокоуровневый язык...