[devel] именование пакетов

[Vitaly Lipatov]

Скрылевъ Малъ писал 13.2.20 23:34:
...
> Заметки к этой таблице таковы, как из неё видно, во-первых для
> некоторых языков программирования используются несколько разных
> хранилищ, так для ruby есть три разных хранилища основное rubygems, и
> специфические puppet и ansible, для python это pypi и conda, для r это
> cran и тот же conda, для perl это cpan и metacpan, для swift это
> родной swiftpm и дополнительные carthage, cocoapods, ну и чемпион js,
> у которого налюдается настоящий бардак: например для системы node как
> правилно используется хранилище npmjs, но пакеты его так устроены, что
> могут быть написаны на чистом js, и ноды и не требовать, это явно
> прописывается в требованиях движка, пакеты хранилища atom
conda это такой облачный rpm, там нет ничего уникального, как я понял, 
поэтому странно было бы на него ориентироваться.
Пакеты npmjs паковать в rpm было бы неправильно, потому что они уже 
упакованы. А вот пакеты для nodejs, использующие нативные библиотеки, 
паковать нужно обязательно, иначе невозможно обеспечить сборку бинарной 
части такого пакета.

Но префикс rpm-пакета должен определяться не хранилищем, а местом, куда 
он будет положен в файловой системе (местом поиска — откуда будут взяты 
его файлы, если угодно). И ассоциироваться такой префекс должен не с 
хранилищем (то есть с сайтом, который и поменяться может), а с названием 
экосистемы для пакетов, среды их исполнения.
Например, так сделано для ruby, python, perl, php. Возможно, кому-то 
показалось, что это названия языков. Но зачастую такие модули написаны 
на C, а не на php :)

Потому что программа восстановления зависимостей (nuget restore, npm 
install, pip install, composer и т.п.) будет (должна) в первую очередь 
смотреть в определённое место в системе, установлен ли пакет, а потом 
уже идти в какое-то хранилище.

> переиспользуют npmjs, но оно длявляется для него второстепенным и к
> ним он добавляет свои зависимости, хранилище bower вообше не
> использует какой либо конкретный движок, и часто его паеты написаны на
> чистом js, а ещё это движок meteor со своим atmospherejs.
Пакеты bower не нужно паковать в rpm. Они не для этого.

> Моё предложением такое ориентироваться по крайней мере в именованиях
> новых пакетов именно на имя хранилища, предлагаемые префиксы для
> которых я поместил в соответствующем столбце таблицы.
Также добавлю о nuget. Это хранилище предлагает пакеты nuget, содержащие 
сборки под все .NET-платформы (от .NET Framework до Xamarin и .NET Core) 
и все архитектуры процессоров (если код не управляемый (т.е. бинарный)).
Например, https://www.nuget.org/packages/NLog
Опять же, никто nuget-пакеты паковать не будет. Будут запакованы 
результаты сборки исходного пакета (в данном случае 
https://github.com/NLog/NLog), причём сборка для mono будет иметь 
префикс mono-, а сборка для dotnet — префикс dotnet-.

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

Мне вот понятно, что паковать что-то из хранилищ, содержащих миллионы 
пакетов, достаточно бессмысленно. Более того, если экосистема удобна для 
того, чтобы внести в пакет с программой все необходимые модули, это и 
нужно делать, пока необходимость компиляции не потребует обратного. Это 
хорошо работает в случае с npm, возможно, но не очень принято для 
python, вроде как неплохо проходит для go.
Главным критерием должно быть отсутствие необходимости вручную повторять 
действия, для автоматизации которых разработана та или иная система 
управления пакетами для языка (платформы).
Я вот, собирая программы, использующие модули python, переношу вручную в 
спек конкретные зависимости с версиями, но это несколько смешно.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team