+6
- 1
- 2
Что вообще за херня, почему для каждого язычка(рантайма) делают свой пакетный менеджер? pip, npm, cabal, Quicklisp, opam, nuget, NPMчо там еще?
И притом все они считают что для языка %LanguageName% всенепременно надо писать пакетный менеджер на нем самом.
Вот например когда я что-то устанавливл через pip, какая-то там херня требует openssl-devel. И узнаю я это только по ошибкам компиляции, ну т.е. там какая-то поебень криптографическая вызывается из питона, оно при установке компилирует через GCC некое говно которое инклудит какое-то .h говно от openssl, но поскольку этого .h нет, оно обламывается на этапе компиляции. Какого хера я про это должен узнавать только на этапе компиляции блядь? Какого хера я должен вручную разруливать эти говнозависимости? А если например будет программа на руби которая использует программу на лиспе, которая использует программу на хаскеле использующую программу на окамле, то что мне, всю эту поеботу тоже руками разруливать по цепочке?
https://blog.versioneye.com/2014/01/15/which-programming-language-has-the-best-package-manager/
какие-то уебни еще сравнивают, какой язык имеет лучший пакетный менеджер... Мудачье! Кто вам сказал что делать для каждого ёбаного языка свой пакетный менеждер это хорошая идея и что среди них может быть "лучший"? Они все говно по определению. Нужно или некое стандартное API для общения между разными пакетными менеджеры разных языков, или один единый пакетный менеджер для всего и под все ОС(а не только Gentoo).
Запостил: j123123,
19 Мая 2016
zenn1989 19.05.2016 10:57 # 0
Притом вас никто не обязывает их использовать, можете по старинке копипастить ваш говнокод и собирать руками без пакетных менеджеров, гита и прочего.
j123123 19.05.2016 11:00 # +4
Потому что они ебаные мудаки, не могущие выбрать один гребаный стандарт для всех говноязычков.
>Притом вас никто не обязывает их использовать, можете по старинке копипастить ваш говнокод и собирать руками без пакетных менеджеров, гита и прочего.
Код собирать тоже нахуй не нужно, можно по старинке дырочки в перфокартах проделывать, тем самым программируя сразу в машинном коде
3_14dar 20.05.2016 14:03 # 0
Секундочку, тут речь идет как раз о пользователях, ставящих чужой софт.
roman-kashitsyn 19.05.2016 11:08 # +3
https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/
roman-kashitsyn 19.05.2016 11:11 # 0
j123123 19.05.2016 11:41 # +2
И почему opam написан на окамле, QuickLisp на лиспе, npm на жабаскрипте, pip на питоне и так далее, зачем к каждому языку писать пакетный менеджер именно на нем? Неужели все они искренне убеждены в том, что именно их язык самый лучший чтобы писать на нем пакетный менеджер к нему же?
roman-kashitsyn 19.05.2016 11:48 # +1
Просто непостижимо, почему сообщества языка X заинтересовано в написании пакетного менеджера на языке X. Может потому, что они хорошо знают X и считают язык X хорошим, раз вкладывают в него время и усилия?
А почему в каждом дистрибутиве линупса свой собственный универсальный пакетный менеджер, с нестандартизированным именованием пакетов и идеологией?
Кто с кем должен собираться и писать "универсальный стандарт упаковки софта 15.0"? Что это изменит? Все дистры линупса резко пересобирут пакеты, виндовс добавит уберменеджер в стандартную поставку?
j123123 19.05.2016 12:03 # +1
Может быть есть такие языки, которые лучше других подходят для задачи написания пакетного менеджера, и лучше использовать их?
>А почему в каждом дистрибутиве линупса свой собственный универсальный пакетный менеджер, с нестандартизированным именованием пакетов и идеологией?
Не в каждом свой. Centos, Fedora, OpenSuse, Redhat, ALT Linux - rpm. Debian, Ubuntu, Mint - deb. С дистрибутивами ситуация явно лучше.
>Кто с кем должен собираться и писать "универсальный стандарт упаковки софта 15.0"?
В Linux Standart Base. Наверняка это все можно организовать, только всем похуй
>Что это изменит? Все дистры линупса резко пересобирут пакеты, виндовс добавит уберменеджер в стандартную поставку?
Как минимум мне не надо будет искать ошибки компиляции питоноговна которое зависит от сишных библиотек и ручками доставлять пакеты из репозиториев
roman-kashitsyn 19.05.2016 12:13 # 0
> deb
Это не пакетные менеджеры, это форматы пакетов. Более того, даже пакеты одного формата (например, RPM), зачастую подходят для использования только на каком-то одном дистре, или на каком-то одном РЕЛИЗЕ дистра.
Даже если речь идёт о rpm / dpkg, то это тоже не полноценные установщики пакетов. Они не умеют автоматически разрешать зависимости, скачивая что-то из интернета. Они только устанавливают то, что уже скачано.
Я как-то жил на системе с одним только rpm, это БОЛЬ.
Люди используют apt-get, apt-rpm, aptitude, yum, smart, zypper, dnf, ... ну вы понели. Зоопарк.
roman-kashitsyn 19.05.2016 12:14 # 0
Пф.... Ну приняли они когда-то RPM в качестве официального стандарта. Ничего не изменилось, всем похер. DEB пакетов уже тогда была в 2 раза больше, никто не будет всё переопакечивать.
roman-kashitsyn 19.05.2016 12:17 # 0
Почему Haskell плохо подходит для написания пакетоного менеджера? Почему CL плохо подходит? Почему Python плохо подходит (на нём, собственно, большая часть линупсовых менеджеров и написана)? Что не так с JS с асинхронной подсистемой IO?
j123123 19.05.2016 12:37 # +3
Какие вообще вещи должен уметь делать пакетный менеджер, если он например из исходников собирает? Разруливание зависимостей между разными версиями разных библиотек, допустим что библиотека X хочет библиотеку Y версии не ниже 1.23 а библиотека Y хочет библиотеку Z версии не ниже 3.33, в то время как библиотека Z хочет библиотеку X версии не ниже 1.33 если ее собирать с поддержкой функции FOO которая нам нужна. ОППА! Circular dependency.
Относительно частое явление в Gentoo. Можно поставить Z без функции FOO и потом собрать Y и X после чего пересобрать Z с функцией FOO, например. И хороший пакетный менеджер должен уметь это разруливать в автоматическом режиме. Задачу можно сформулировать в терминах ... эээ ... графов зависимостей? Выполнимости неких условий? А почему б не использовать для этого SAT/SMT солверы? Ну вот на вход солверу задаем того, чего мы там хотим достичь(собрать такой-то пакет из исходных кодов), он может выдать некое решение, или даже несколько возможных путей достижения поставленных целей. Можно добавить неких ограничений, например "попробуй-ка разрули тут зависимости, не ставя пакеты A B C" и тогда решатель должен решать с учетом этих ограничений. SMT солверы используются хоть в одном пакетном менеджере?
roman-kashitsyn 19.05.2016 12:44 # 0
j123123 19.05.2016 12:51 # 0
j123123 19.05.2016 12:41 # 0
Вообщем, я к тому веду, что надо выбирать подходящий под задачу язык, а не писать пакетный менеждер на том же языке, пакеты к которому он обслуживает(просто потому что они хорошо знают этот язык и считают его хорошим)
roman-kashitsyn 19.05.2016 12:45 # 0
Для асинхронного IO, ага.
j123123 19.05.2016 12:49 # 0
roman-kashitsyn 19.05.2016 12:59 # 0
j123123 19.05.2016 13:08 # +2
wvxvw 19.05.2016 14:21 # +1
1024-- 19.05.2016 20:03 # 0
А почему нельзя взять хороший пакетный менеджер от другого языка и заменить там в конфигурации имя языка и путь к репозиторию?
Дальше бы вкладывали время и усилия в язык X, а не в питушню, которую уже без них написали...
bormand 19.05.2016 20:12 # +2
kipar 20.05.2016 09:36 # +2
Во-вторых да, сообщество языка X считает язык Y говном по определению, и потому хорошего менеджера на этом языке просто не может быть. Даже если не всё сообщество, даже если 1% - не стоит этот менеджер 1% настоящих фанатов.
Ну и в-третьих - "а что у вас в Х даже своего менеджера нет? Настолько язык убогий? Небось асинхронный IO не осилили?"
1024-- 20.05.2016 10:49 # 0
Надеюсь, остались ещё компилируемые языки. Тогда, хоть это и достаточно жёстко, можно требовать только наличие компьютера.
> Во-вторых
> в-третьих
Печалька. С этим фиг разберёшься в ближайшие тысячелетия.
dxd 20.05.2016 12:44 # 0
3_14dar 20.05.2016 13:59 # 0
scph77008 19.05.2016 12:34 # 0
roman-kashitsyn 19.05.2016 11:58 # +4
Системные пакетные менеджеры абстрагируют от детелаей конкретных языков и позволяют получать более-менее стабильные версии работающих вместе программ. Это титаническая работа, на самом деле. Подобрать версии свободного софта, которые компилируются и нормально работают вместе - задача NP-трудная :)
Языковые пакетные менеджеры абстрагируют от деталей управления софтом в системе, и часто не требуют права суперпользователя, позволяя использовать самые свежие версии софта.
Пользователю удобнее первые, а разработчику - вторые.
dxd 19.05.2016 13:36 # +2
roman-kashitsyn 19.05.2016 14:44 # +1
Недаром люди stack придумали.
А opam у меня вообще сам по себе постоянно ломался, и я забил на Ocaml.
3.14159265 19.05.2016 18:51 # +1
6E3yMHblu_nemyx 22.02.2019 16:42 # 0
Кстати, заметил особенность «opam»: он умеет даунгрейдить пакеты, если у какого-нибудь пакета в требованиях указан верхний порог версии.
Dummy00001 19.05.2016 18:28 # +1
как если бы что-то новое. у меня как-то раз в сиде апдейты неделю не ставились. мелочи по сравнению с тем как я раз форс сделал, и апт мне пол системы (включая гуи) удалило (но проапдейтило ту пару пакетов которые я хотел....).
ЗЫ
https://wiki.debian.org/Teams/ReleaseTeam/Transitions
https://release.debian.org/transitions/ -
лол. окамл и хаскелл - "Permanent trackers".
что означает что либо у языков релиз процесс дерьмо, либо дебьяновы мэнтейнеры мудаки. очень часто первое - но изредка и второе.
bormand 19.05.2016 18:40 # 0
Это типа всегда самый последний коммит и хуй с ними, пусть сами разбираются? Или что-то другое?
Dummy00001 19.05.2016 18:47 # +1
> Это типа всегда самый последний коммит? Или что-то другое?
Нет, это означает что почти всегда что-то не работает, потому что где-то что-то надо фиксить или где-то что-то опять в языке поменялось.
Transitions - это когда хотят залить новую версию проги/либи, и в дистре гарантировано что-то сломается (или уже сломалось) с результате аплоада.
bormand 19.05.2016 18:48 # 0
Dummy00001 19.05.2016 19:02 # 0
с точки зрения дистра, ответственный это мэнтейнер, и на его решении все и основывается. но если мэнтейнер идиот, то релиз мастеры для критического софта могут просто откатится на старую версию.
по какой именно причине окамл и хаскелл на перманентном трэкере - я не знаю.
bormand 19.05.2016 19:05 # +1
И прилетает всем юзерам сида?
Dummy00001 19.05.2016 20:54 # 0
dxd 19.05.2016 21:14 # 0
3.14159265 19.05.2016 18:48 # +3
Хацкель - это круто. Не то что заедушные жабисты с своим занудным backward compability и вечным говном мамонта.
bormand 19.05.2016 18:50 # +1
З.Ы. Вон рубисты, питонисты и нодовцы тоже вечно ломают совместимость либ. Но всем похуй, т.к. virtualenv.
3.14159265 19.05.2016 18:52 # +5
он и так нахуй никому не нужен (кроме выебщиков).
CHayT 19.05.2016 18:56 # +4
j123123 10.07.2016 03:49 # +2
http://bitcheese.net/art_thou/images/full/real_world/haskell-coder.png
tau 20.05.2016 01:53 # 0
roman-kashitsyn 20.05.2016 15:27 # 0
> он и так нахуй никому не нужен
Мозилле такой нужен
3.14159265 20.05.2016 16:49 # 0
Ага, и потому они придумали свою питушню (раст).
CHayT 20.05.2016 22:52 # +2
раст -- это как борщ из железного питуха
guesto 11.07.2016 01:51 # 0
MAMOHT 03.12.2018 06:07 # 0
Ну хоть что-то у меня вечное.
3.14159265 19.05.2016 14:06 # +1
gaven забыл. и composter
Her 19.05.2016 14:31 # 0
Her 19.05.2016 14:34 # 0
gem, bower
Zuzik 19.05.2016 15:44 # 0
Плюс к этому - свой пакетный менеджер/дистрибутив линукса - очень большой плюс к ЧСВ. Да и согласитесь - что более красиво "Я один из 20 разработчиков ..." или "Я один из 300 разрабтчиков ...". Если ты в числе 20 человек - больше шанс, что тебя заметят, конечно, если заметят, ту никому не нужную херню, которую ты разрабатываешь.
Как то так.
Обобщим это высказываение до различных программ одного назначения. Согласитесь, нередко зоопарк различных файловых менеджеров, текстовых редакторов, графических редакторов и прочее, прочее, ппрочее с открытым исходным кодом заставлял задуматься - где же меньше всего багов, что лучше всего работает, что лучше поддерживает существующие стандарты, либо вообще их поддерживает. И опять же сталкиваемся с проблеммой - слишком много людей, желающих поднять свое ЧСВ. Попытки стандартизации, создать что либо единое - еще один обитатель зоопарка занял свою нишу, либо умер так и не родившись.
Все печально, выхода из ситуации не видно...
Dummy00001 19.05.2016 18:42 # +1
ты перепрыгнул самое главное препятствие: признанаться что кто-то другой что-то лучше чем ты сделал. шутка.
но самая главная проблема что два центральных дистра - RH & Debian - они просто живут по разным релиз циклам.
даже если формат пакетов стандартизируешь, толку будет мало если все пользуются разными версиями пакетов.
Debian & Ubuntu работает только по тому что Ubuntu ориентируется на дебьяновские версии и конфигурации пакетов.
А с RH-based, там никто никогда с друг другом договорится не мог, начиная с RH который имеет привычку в разных вариантах разные версии использовать.
"Все печально, выхода из ситуации не видно..."
У всех (людей, дистро) разные требования. Как только требования начнут стабилизироваться, начнется и унификация.
Но редактора, файл-манагеры и граф-редакторы можешь забыть: проф/энтузиаст софт никогда не будет унифицирован потому что у всех power-user/более есть свои уникальные требования, и если эти требования не выполняются, народ пишет еще одну версию софта.
Zuzik 19.05.2016 19:25 # +1
В некоторых случаях это не шутка, апечальная правда
3.14159265 19.05.2016 18:55 # +7
xkcd и 14 стандартов.
3_14dar 20.05.2016 14:00 # 0
Сука, такая же хрень с pycurl. Что нужно доустановить, можно узнать только загуглив ошибку, ИЧСХ доустанавливать нужно через ПМ прыщей.
3_14dar 20.05.2016 14:02 # 0
3.14159265 20.05.2016 17:01 # 0
3.14159265 20.05.2016 17:02 # 0
3.14159265 20.05.2016 17:02 # 0
3.14159265 20.05.2016 17:03 # 0
3.14159265 20.05.2016 17:04 # −1
3.14159265 20.05.2016 17:05 # +3
inkanus-gray 20.05.2016 17:42 # +5
CHayT 20.05.2016 19:45 # 0
3.14159265 20.05.2016 19:56 # +2
inkanus-gray 20.05.2016 22:14 # +6
— Говорил я тебе, дура старая, что в банке говно, а ты: «Засахарилось! Засахарилось!»
bormand 20.05.2016 22:18 # +4
Кстати, можно же ворьировать проги на лишпе. Они от этого не особо пострадают. Лишь бы баланс скобок не нарушался.
3.14159265 20.05.2016 22:25 # +5
я такую шнягу для J сделал. но кегдан больше не форсит, потому испытывать не на ком.
bormand 20.05.2016 22:39 # 0
inkanus-gray 20.05.2016 22:51 # 0
bormand 20.05.2016 22:58 # +2
inkanus-gray 20.05.2016 22:59 # +3