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

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

[Скрылевъ Малъ]

Приветствую всех,

Тут уже какой раз встаёт вопрос о именовании пакетов, на что я решил написать коротное разыскание. И оно выразилось в следующей таблице.

Номера и толкование столбцов и саму таблицу я привожу ниже:

1. имя хранилища пакетов
2. количество пакеток на сегодня
3. употребляемый язык программирования для написания библиотек для хранилища
4. наименование системы разработки, движка, или облака для этого хранилища
5. предлагаемый префикс

1                  2                                 3             4          5

npmjs         1,302,589            js             node/pure   npmjs-
atom             12,904               js             atom        atom-
bower            69,684              js             pure        bower-
atmospherejs     13,410           js             meteor      atmospherejs-
crates           37,102                rust           cargo       crate-
carthage          3,945               swift/c/objc   cocoa       carthage-
cocoapods        68,857           swift/c/objc   cocoa       cpod-
swiftpm           4,207                swift          swiftpm     swiftpm-
clojars          24,295                clojure        clojars     clojar-
cran             16,880                 r              r           cran-
conda             1,935               python/r       anaconda    conda-
pypi            237,491               python         pypi        pypi-
metacpan         37,628           perl           metacpan    metacpan-
cpan            185,296              perl           cpan        cpan-
dub               1,920                d              dub         dub-
elm               1,505                  elm            elm         elm-
go            1,818,640                go             go          go-
hackage          14,585             haskell        hackage     hackage-
haxe              1,436                  haxe           haxelib     haxe-
hex               9,578                 erlang/elixir  hex         hex-
julia             3,048                  julia          julia       julia-
maven           185,034          pom            java        maven-
nuget           201,136           c#/vb/ps       .net/mono   nuget-
packagist       317,896           php            packagist   packagist-
pub              10,657              dart           flutter     pub-
shards               33              crystal        shards      shard-
gems            162,413           ruby           rubygems    gem-
puppetforge       6,396         ruby           puppet      puppet-
ansiblegalaxy    23,850         ruby           ansible     ansible-



Заметки к этой таблице таковы, как из неё видно, во-первых для некоторых языков программирования используются несколько разных хранилищ, так для ruby есть три разных хранилища основное rubygems, и специфические puppet и ansible, для python это pypi и conda, для r это cran и тот же conda, для perl это cpan и metacpan, для swift это родной swiftpm и дополнительные carthage, cocoapods, ну и чемпион js, у которого налюдается настоящий бардак: например для системы node как правилно используется хранилище npmjs, но пакеты его так устроены, что могут быть написаны на чистом js, и ноды и не требовать, это явно прописывается в требованиях движка, пакеты хранилища atom переиспользуют npmjs, но оно длявляется для него второстепенным и к ним он добавляет свои зависимости, хранилище bower вообше не использует какой либо конкретный движок, и часто его паеты написаны на чистом js, а ещё это движок meteor со своим atmospherejs. 

Во-вторых для написания пакетов для некоторых хранилищ используются несколько языков программирования, например: для carthage и cocoapods это три языка: swift, c и objc, для conda это python и r, для nuget это все мелкомягкие языки (те что в mono) , а для hex это elixir и erlang. 

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

Моё предложением такое ориентироваться по крайней мере в именованиях новых пакетов именно на имя хранилища, предлагаемые префиксы для которых я поместил в соответствующем столбце таблицы.
Мне всыказывались мнения, что было бы хоро понимать также несведущим в хранилищах к какому языку относится пакет, это моно решить указываем его явно в каком либо свободном формате в автоматическом provide.
Имена пакетов со старых подходом  в принципе можно и не  особо менять.



-- 

Малъ Скрылевъ
about.me/majioa

Re: [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

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

[Vladimir D. Seleznev]

On Fri, Feb 14, 2020 at 03:00:24AM +0300, Vitaly Lipatov wrote:
> Скрылевъ Малъ писал 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 :)

Именно! Префикс имени пакета для языковых систем показывает, расширение
какого языка поставляет этот пакет. И совершенно не важно, из какого
хранилища приехал этот пакет.

-- 
   С уважением,
   Владимир Селезнев

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

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 4079 bytes --]


On Mon, 17 Feb 2020, Vladimir D. Seleznev wrote:

> On Fri, Feb 14, 2020 at 03:00:24AM +0300, Vitaly Lipatov wrote:
> > Скрылевъ Малъ писал 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 :)
> 
> Именно! Префикс имени пакета для языковых систем показывает, расширение
> какого языка поставляет этот пакет. И совершенно не важно, из какого
> хранилища приехал этот пакет.

Ну бывают такие язык-специфичные системы управления пакетами, которые 
видят, что уже стоит из пакетов из дистрибутива в системе, и при 
необходимости сам доставляют ещё какие-то.

Тогда может иметь смысл как-то отмечать, что наш пакет будет этой системой 
понят.

Не уверен, что название яхык-специфичной системы управления пакетами всё 
же совпадёт с названием репозитория. Например, есть hackage, stackage (на 
Haskell), а пакетный менеджер, наверное, в основе один и тот же...

-- 
Best regards,
Ivan

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

[Dmitry V. Levin]

On Thu, Feb 13, 2020 at 11:34:58PM +0300, Скрылевъ Малъ wrote:
> Приветствую всех,
> 
> Тут уже какой раз встаёт вопрос о именовании пакетов, на что я решил написать коротное разыскание. И оно выразилось в следующей таблице.
> 
> Номера и толкование столбцов и саму таблицу я привожу ниже:
> 
> 1. имя хранилища пакетов
> 2. количество пакеток на сегодня
> 3. употребляемый язык программирования для написания библиотек для хранилища
> 4. наименование системы разработки, движка, или облака для этого хранилища
> 5. предлагаемый префикс
> 
> 1                  2                                 3             4          5
> 
> npmjs         1,302,589            js             node/pure   npmjs-
> atom             12,904               js             atom        atom-
> bower            69,684              js             pure        bower-
> atmospherejs     13,410           js             meteor      atmospherejs-
> crates           37,102                rust           cargo       crate-
> carthage          3,945               swift/c/objc   cocoa       carthage-
> cocoapods        68,857           swift/c/objc   cocoa       cpod-
> swiftpm           4,207                swift          swiftpm     swiftpm-
> clojars          24,295                clojure        clojars     clojar-
> cran             16,880                 r              r           cran-
> conda             1,935               python/r       anaconda    conda-
> pypi            237,491               python         pypi        pypi-
> metacpan         37,628           perl           metacpan    metacpan-
> cpan            185,296              perl           cpan        cpan-
> dub               1,920                d              dub         dub-
> elm               1,505                  elm            elm         elm-
> go            1,818,640                go             go          go-
> hackage          14,585             haskell        hackage     hackage-
> haxe              1,436                  haxe           haxelib     haxe-
> hex               9,578                 erlang/elixir  hex         hex-
> julia             3,048                  julia          julia       julia-
> maven           185,034          pom            java        maven-
> nuget           201,136           c#/vb/ps       .net/mono   nuget-
> packagist       317,896           php            packagist   packagist-
> pub              10,657              dart           flutter     pub-
> shards               33              crystal        shards      shard-
> gems            162,413           ruby           rubygems    gem-
> puppetforge       6,396         ruby           puppet      puppet-
> ansiblegalaxy    23,850         ruby           ansible     ansible-
> 
> 
> 
> Заметки к этой таблице таковы, как из неё видно, во-первых для некоторых языков программирования используются несколько разных хранилищ, так для ruby есть три разных хранилища основное rubygems, и специфические puppet и ansible, для python это pypi и conda, для r это cran и тот же conda, для perl это cpan и metacpan, для swift это родной swiftpm и дополнительные carthage, cocoapods, ну и чемпион js, у которого налюдается настоящий бардак: например для системы node как правилно используется хранилище npmjs, но пакеты его так устроены, что могут быть написаны на чистом js, и ноды и не требовать, это явно прописывается в требованиях движка, пакеты хранилища atom переиспользуют npmjs, но оно длявляется для него второстепенным и к ним он добавляет свои зависимости, хранилище bower вообше не использует какой либо конкретный движок, и часто его паеты написаны на чистом js, а ещё это движок meteor со своим atmospherejs. 
> 
> Во-вторых для написания пакетов для некоторых хранилищ используются несколько языков программирования, например: для carthage и cocoapods это три языка: swift, c и objc, для conda это python и r, для nuget это все мелкомягкие языки (те что в mono) , а для hex это elixir и erlang. 
> 
> Для стороннего разработчика же как пользователя нажего репозитория важно понимать именно к какому хранилищу пакет относится, а не на каком языке он написан, это второстепенно, если скажем я программирую на elixir-е, то вполне под именованием пакета как hex- ожидаю встретить по зависимостям пакет на erlang, потому что так принято в том сообществе.
> 
> Моё предложением такое ориентироваться по крайней мере в именованиях новых пакетов именно на имя хранилища, предлагаемые префиксы для которых я поместил в соответствующем столбце таблицы.
> Мне всыказывались мнения, что было бы хоро понимать также несведущим в хранилищах к какому языку относится пакет, это моно решить указываем его явно в каком либо свободном формате в автоматическом provide.
> Имена пакетов со старых подходом  в принципе можно и не  особо менять.

Надеюсь, никто не воспримет это предложение иначе как шутку.


-- 
ldv

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

[Anton Farygin]

On 18.02.2020 15:42, Dmitry V. Levin wrote:
>> Моё предложением такое ориентироваться по крайней мере в именованиях новых пакетов именно на имя хранилища, предлагаемые префиксы для которых я поместил в соответствующем столбце таблицы.
>> Мне всыказывались мнения, что было бы хоро понимать также несведущим в хранилищах к какому языку относится пакет, это моно решить указываем его явно в каком либо свободном формате в автоматическом provide.
>> Имена пакетов со старых подходом  в принципе можно и не  особо менять.
> Надеюсь, никто не воспримет это предложение иначе как шутку.

Автор точно не считает это шуткой:
http://git.altlinux.org/tasks/245637/