Re: [devel] Языковые экосистемы

[Vitaly Lipatov <lav@altlinux.ru>]

Yury A. Romanov писал 10.3.18 0:16:
...
> Поэтому наверное наиболее годным вариантом было бы паковать вместе с
> исходником пакета кэш сборочной системы, из которой его можно было бы
> собрать без внешних зависимостей.
Что я, например, достаточно давно и делаю, и для случая с npm даже почти 
автоматически.

Тут есть некоторые крайности. В случае с python вполне хорошо держать 
все модули упакованными в системе (их не так много). В случае с perl я 
бы предпочёл модули паковать в программу, но модуль perl может 
потребовать некоторой интеграции с системой, и вообще исторически они у 
нас тоже все упакованы.

В случае с npm бывают модули, которые либо прилетают с бинарниками, либо 
начинают что-то там линковать. Конечно, такие надо паковать в систему, 
чтобы персонально с ними разобраться.

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

Как я понимаю, с Java ничего не изменилось: поскольку проекты приняты 
собирать и носить вместе со всеми библиотеками (jar), мы во время сборки 
пакета искусственно разделяем, проставляя вместо файлов ссылки на 
отдельные jar из пакетов. Тут вопрос, а настолько ли мы ценим Java, что 
готовы влезать в проект и пытаться его заставить работать с чем-то 
непроверенным.

Есть модный go (очень нравится, что в итоге получается один бинарник, но 
никак не хочется паковать отдельные модули, которые и нужны-то только 
для сборки).

Ну с ruby история плоха тем, что там и среда запуска и библиотеки 
принципиально должны быть не такими как в системе, а самыми 
распоследними, и этот подход кажется странным.

Хочу заметить, что в случаях Java и .NET, если мы сами не соберём 
модуль, он к нам прилетит в уже собранном виде, что противоречит 
концепции сборки всего из исходников.

Для тех модулей, которые мы хотим видеть в Сизифе, я бы предпочёл 
зависимости с кэшированием.
Чтобы не
> И второй: написать плагины для apt, которые бы работали с
> апстримными, _не RPM_ репозиториями. Чтобы в спеке можно было написать
> что-то вроде:

>   Requires: nmp::my-favorite-lib

А чтобы можно было запросить (хоть через тот же (Build)Requires), какие 
модули нужны, и они автоматически собирались в Сизиф и обновлялись после 
этого.
То есть не вручную собираем пакеты, и не мимо Сизифа ставим, а 
автоматически пропускаем модули через rpm-репозиторий, где они обретают 
форму, проходят все необходимые проверки, обзаводятся локальными 
репозиториями, и в дальнейшем автоматически обновляются. При этом мы 
реально пакуем только то, что нужно (популярно) а не весь репозиторий 
(100 тыс. пакетов npm).

Конечно, остаётся проблема с требованием разных версий, но она несколько 
надумана (может, это во время разработки и допустимо, но использовать 
набор разных версий одной библиотеке в сопровождаемом проекте не очень 
хорошо).


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