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
Все эти версии можно ставить параллельно (или создать собственные), и они никак не будут влиять друг на друга. И в них поставить все нужные пакеты нужных версий в рамках необходимого стека.
А системный стек - для системных приложений.
Deleted ()
Последнее исправление: Deleted
(всего
исправлений: 2)
Но мне это не надо. Это ты ноешь об отсутствии кооперации между cargo и системного ПМ.
При сборке каждой зависимости, требующей либ не из растомира нужно плакать и руками сочетать два ПМ.
И каким образом отсутствие cargo этому поможет?
Слой кода, отвечающий за сборку с внешними зависимостями, не был бы гвоздями прибит к импотентному и некооперирующемуся cargo. Сейчас или сам вызывай rustc, или пересобирай мир по правилам cargo, среднего не дано.
Проведи мысленный эксперимент: представь, что cargo не существует - каким образом это облегчит «сборку с внешними зависимостями» или какую там задачу ты пытаешься решить?
Потому что вы неправильно пользуетесь прикладным ПМ. Он должен не затенять, а полностью переопределять и реализацию языка, и всё пространство имён пакетов.
Это свойство ценно только в случаях, когда системный ПМ убог и неспособен поставить несколько реализаций языка и пространств имен пакетов одновременно. Это как вкладки в браузере - костыльное следствие импотенции window management'а и не более того.
Нужен один ПМ, который умеет в окружения, изоляцию, пользовательские профили и знает про абсолютно весь софт в системе.
Это ты ноешь об отсутствии кооперации между cargo и системного ПМ.
И мне это в apt не надо. Я ною про nixos. А там эта проблема уже решена, однако не в пользу дурацкого cargo.
Проведи мысленный эксперимент: представь, что cargo не существует - каким образом это облегчит «сборку с внешними зависимостями» или какую там задачу ты пытаешься решить?
Нет такого сценария. Ниша в экосистеме пустеть не будет, что-то да будет выполнять эти две роли. Было бы круто, если это был бы не монолитный cargo.
Это свойство ценно только в случаях, когда системный ПМ убог и неспособен поставить несколько реализаций языка и пространств имен пакетов одновременно.
С какой стати приложение, разворачиваемое на локалхосте под конкретную задачу, должно зависеть от системного ПМ? Локалхост вообще может оказаться в реальности докер-контейнером с голой базовой системой и без ПМ.
Вам еще не пришла в голову идея заменить утилиту make на ПМ? Это в духе вашего предложения.
Нужен один ПМ, который умеет в окружения, изоляцию, пользовательские профили и знает про абсолютно весь софт в системе.
У меня /builds/ служит симлинком на $HOME/my/projects/builds/ , в котором лежит куча скомпилированного добра, начиная от пропатченных под одну конкретную задачу утилит, до софта, который я разрабатываю и отлаживаю прямо сейчас. Про этот каталог тоже ПМ должен знать?
Может и будет, но проблема не с этой стороны. Проблема в том, чтобы ее потом скормить при сборке другого крейта. Неуемную пакетно-менеджментную часть cargo не остановить, она все равно пытается полезть в сеть и пытается сделать все-все-все сама. Набор флагов, его урезонивающий, пригоден для пересборки проекта в самолете со старым Cargo.toml и валидным кешем, но никак не для сборки в чистом окружении с известными путями зависимостей.
Набор флагов, его урезонивающий, пригоден для пересборки проекта в самолете со старым Cargo.toml и валидным кешем, но никак не для сборки в чистом окружении с известными путями зависимостей.
Я ною ради выявления мирового идиотизма зоопарка ПМ вообще и cargo в частности. Если «Лучший менеджер зависимостей» проще выкинуть по самый rustc, то это былинный отказ.
Но, я надеюсь, ты услышал, что в моем идеальном мире патч нужен не на cargo. Патч нужен на дурацкую идею, что каждый язык должен иметь свой, по особенному импотентный ПМ.
С какой стати приложение, разворачиваемое на локалхосте под конкретную задачу, должно зависеть от системного ПМ? Локалхост вообще может оказаться в реальности докер-контейнером с голой базовой системой и без ПМ.
С той, что лучше зависеть от системого ПМ, чем от его брата-импотента из поставки языка.
Вам еще не пришла в голову идея заменить утилиту make на ПМ? Это в духе вашего предложения.
Не язви, гранулярность не та.
У меня /builds/ служит симлинком на $HOME/my/projects/builds/ , в котором лежит куча скомпилированного добра, начиная от пропатченных под одну конкретную задачу утилит, до софта, который я разрабатываю и отлаживаю прямо сейчас. Про этот каталог тоже ПМ должен знать?
Да, именно! Как только они перестают быть листьями дерева зависимостей и становятся кому-то нужны, в дело должен вступить ПМ.
Почитай, если интересно, какая философия у Nix. Там как раз вся эта шелуха с виртуальными окружениями, изоляцией «параллельно установленных» пакетов и насильным использованием единого ПМ для всего-всего сделана максимально правильно, аж забрызгивает максимализмом.
Да, было бы здорово. Да, к сожалению apt принципиально очень примитивен в этом плане.
Айда на NixOS! Единой системой она вряд ли станет, но как прототип самого правильного в мире ПМ очень даже годна. Надеюсь ПМ будущего научатся у Nix хоть половине его годноты.
Да нет, не один. Дистрибутивов с ванильным софтом довольно много.
Я сейчас пробежался по nixpkgs. Там меньше 2000 патчей в сумме, все или почти все правят сборку (пути, зависимости и т.д.). Правкой кода, закрытием дыр и бэкпортом фич занимаются разве что Debian и Red Hat, а также производные дистрибутивы. Остальным проще новую версию опакетить.
Стрелять в девелоперскую машину, в тестеров и в продакшен из одного ружья.
Не язви, гранулярность не та.
Вот она и в обсуждаемой задаче не та, а ты всё равно хочешь натянуть сову на глобус. Что делать?
С той, что лучше зависеть от системого ПМ
Несуществующего?
Да, именно! Как только они перестают быть листьями дерева зависимостей и становятся кому-то нужны, в дело должен вступить ПМ.
Они нужны мне. И мне они в системе не нужны.
Почитай, если интересно, какая философия у Nix.
Я знаю, как устроен Nix.
Но, я надеюсь, ты услышал, что в моем идеальном мире патч нужен не на cargo. Патч нужен на дурацкую идею, что каждый язык должен иметь свой, по особенному импотентный ПМ.
И вообще много по своему особенных языков - это бардак. Язык должен быть один.
Это ж нифига себе ты подкинул задачку мейнтейнерам дистров. Опакетить все rust либы из интернета
Во-первых, задачку подкинул не я - это объективная необходимость.
Во-вторых, всё совершенно не надо, тем более из интернета. crates.io обречён превратиться в такую ще помойку как cpan, pypi, gems и всё что было до него, реально использоваться оттуда будут проценты пакетов, их и нужно будет, точнее придётся, опакетить.
В-третьих, ничего нового в этом нет, так делали всегда,
leftpad - это следствие некомпетентности разработчиков на JS и ошибки дизайна npm. От этого невозможно защититься.
Да нет, это следствие использование обособленного немодерируемого репозитория. В crates.io возможно если не внезапное удаление автором любого своего crate, то любое другое западло включая неисправленные уязвимости и полностью сломанные пакеты. И всё это вылезет когда кто-то захочет таки обновиться. И даже патч некуда будет добавить.
Тогда не жалуйся.
Мне не на что жаловаться, я сломанными пакетными системами не пользуюсь. Но кто-то может в это наступить, а кто-то намеренно замалчивает проблемы, так что молчать я не собираюсь.
что ты не привел ровно никаких доказательств или хотя бы доводов.
Целая пачка, которую ты не удосужился даже процитировать.
leftpad - это следствие некомпетентности разработчиков на JS и ошибки дизайна npm. От этого невозможно защититься.
Да нет, это следствие использование обособленного немодерируемого репозитория.
Да нет, это следствие использования неподконтрольного репозитория для сборки ответственных приложений. Тем более непростительное, учитывая, что npm позволяет создавать локальные зеркала. cargo этого, кстати, не позволяет пока, но это технический недостаток, а не принципиальный.
Что ещё за бред про системный ПМ который ставит либы для хруста, лол. Там кто-то запостил мега-профитную либу, а ты тут ждёшь такой на сервере или где-то, на говне мамонта-дебиане, вот вот, сейчас, ещё 2.5 года до нового релиза.
И ещё 100500 говнодистров заментейнить на все библиотеки хруста, рили?
Нет, конечно. Значит это должен быть ПМ, опакечивающий растовые либы в одну команду, че.
Хватит тут со своими представлениями об импотентных ПМ рассказывать, что ПМ должен, а что нет. Должен, а то, что он этого не делает - досадное недоразумение, идеальной картины мира не меняющее.
В расте есть модель менеджмента памяти, которой нет в аде. В т.ч. гарантия memory safety и отсутствие гонок данных в многопоточных приложениях. ИМХО, на практике это намного профитнее пресловутых контрактов ады. Контракты, если так хочется, можно и руками написать, а модель владения и заимствований — не так просто. В GLib написали для сишки, но лишь на уровне конвенции, следить за соблюдением все равно программисту.