это второй пакетный менеджер? всегда не любил всякие питоньи яйца, рубиновые камни и т.п.
Зачем всё это, если пакетами отлично управляет системый пакетный менеджер.
При том что я про С говорю. Который замечательно обходится без своего менеджера. Как обойдётся любой другой язык. С одной стороны да удобно иметь способ унифицировано получать последние наработки с единого места (или зеркал не важно), но не жизненно необходимо.
Ты прав, но тогда под понятие непрекрасности попадают вообще все и языковые и системные менеджеры, потому что идеала нет и не будет, везде есть минусы и плюсы. Плюс языкового ну, большая актуальность, плюс системного большая строгость и оттестированность с минусами наоборот. Победителей тут не было и не будет, за исключением того случая когда вся система на одном языке написана и для одного языка создана, тогда да.
Ты прав, но тогда под понятие непрекрасности попадают вообще все и языковые и системные менеджеры
Я не знаю, какой смысл ты вкладываешь в понятие «непрекрасность», но у языкового менеджера пакетов есть минимум два существенных преимущества: 1) в отличие от системного ПМ, которые хочет доступ к системным файлам и каталогам, языковый ПМ локален для юзера; 2) пользователь языкового ПМ не зависит от релизного цикла дистрибутива и ресурсов мейнтенера дистрибутивного пакета.
Ада это старинный язык из 40-х, Rust это современный язык. Как их можно сравнивать. Ты щас и компилятора ады не найдёшь, если сканер перфокарт в чулане не завалялся.
Да не, чистая правда. Системный ПМ даёт модерацию, тестирование и предсказуемость сборки над помойками пакетов типа PyPi или Gems. Через системный менеджер мне не прилетит какая-нибудь colourama или smplejson даже если я опечатаюсь, и на разных машинах мне гарантировано прилетит одна и та же версия, не подмененная ни в хранилище, ни в полёте, ни обновлённая внезапно с потерей совместимости.
Только вот с rust'ом тут проблема - он своими сраными crates с системными пакетами не совместим никак.
Системный ПМ даёт модерацию, тестирование и предсказуемость сборки
Первое — обычно да. Второе и третье — вряд ли.
на разных машинах мне гарантировано прилетит одна и та же версия, не подмененная ни в хранилище, ни в полёте, ни обновлённая внезапно с потерей совместимости.
Круче всего повторяемая сборка сделана в Haskell с помощью stack. В Rust вроде что-то похожее тоже пилят.
Алсо, в Rust можно и нужно указывать версии зависимостей. Это тебе не golang.
«Опакечивание» не сводится к упаковке в дистрибутивно-специфичный пакет - подразумевается еще как минимум исправления ошибок и дыр. С этим тоже скрипт справится?
И почему же нефиг? Расскажи подробно. Почему держать два компилятора можно, два браузера - можно, а два ПОм - нет?
Потому что два браузера не взаимодействуют, два компилятора - тоже, а вот три ПМ - еще как.
Один и тот же пакет на Debian Buster с Anaconda можно поставить через apt «в систему», через conda «в систему», через conda «в пользователя», через pip «в систему», через pip «в пользователя». Это - ад.
Вот в этом твоя ошибка. cargo и системный ПМ «кооперируются» от «слабо» до «никак».
Ага, об этом и ною. При каждой сборке расто-пакета приходится либо пересобирать из нифига весь растомир, либо выкидывать каргу и велосипедить ее замену (buildRustPackage в nixos). При сборке каждой зависимости, требующей либ не из растомира нужно плакать и руками сочетать два ПМ.