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

[Vladimir D. Seleznev]

On Tue, Mar 06, 2018 at 12:43:12PM +0300, Paul Wolneykien wrote:
> 05.03.2018 20:12, Eugene Prokopiev пишет:
> > Апстримы рекомендуют maven/gradle, npm/yarn,
> > rubygems, cpan и прочие pip/virtualenv для библиотек, а еще
> > sdkman/nvm/rvm и т.д. для выбора рантайма
> > ...
> > У этого способа есть критически важное преимущество - он работает.
> > ...
> > java/ruby/ocaml/nodejs/texlive с высокой вероятностью вылетают в
> > дополнительные компоненты
> 
>   Лично я всеми конечностями за хороший преинсталл для TeXLive, NodeJS,
> Go и т.д. То-есть за удобный способ установки пакетов из апстрима. Это
> действительно удобно, пока ты пользователь _апстрима_.
> 
>   Но ситуация меняется, как только ты из пользователя апстрима
> превращаешься в писателя пакетов для Сизифа на этом языке. Сразу же
> хочется, чтобы написанная тобой программа, будучи установленной из
> Сизифа, работала бы. А значит, были установлены все нужные ей библиотеки.
> 
>   И тут я вижу два пути. Первый — паковать всё в Сизиф (как мы сейчас и
> делаем). И второй: написать плагины для apt, которые бы работали с
> апстримными, _не RPM_ репозиториями. Чтобы в спеке можно было написать
> что-то вроде:
> 
>   Requires: nmp::my-favorite-lib
> 
>   **IMHO** Первый путь — тупиковый, ибо в пределе Сизиф становится
> [мёртвой] копией всех пакетов в мире. Второй путь — перспективный, ибо в
> нём Сизиф (apt) устанавливает *живой* контакт с другими репозиториями,
> пакетными базами — становится узловой точкой, соединяющий дистрибутивы.

Увы, второй путь бесперспективен для Сизифа, по крайней мере в области
сборки пакетов точно.

Что значит "[мёртвая] копия всех пакетов в мире"? В Сизиф есть только те
пакеты, которые были собраны в Сизиф ;). Другое дело, что мы сознательно
архивируем программное обеспечение и храним вместе с нашими изменениями,
такое архивирование решает несколько задач, в т.ч. и по верификации
наших сборок. Использование сторонних репозиториев со сторонними
форматами пакетов лишит нас возможности проверять воспроизводимость,
качество пакетов, и самого понятия стабильности, учитывая эфемерность
пакетной базы таких репозиториев как nmp и странное отношение этого
сообщества к требованиям стабильности и работоспособности как их
пакетной базы, так и репозитория и инфраструктуры.

Помимо этого есть технические препятствия: какой бы предполагался
протокол общения с неким сторонним репозиторием, как происходила бы
интеграция его программного обеспечения в рабочее окружение,
построенного на нашей пакетной базе, и обеспечивалась их
работоспособность. На самом деле сложные вопросы как и в плане
реализации, так и в плане поддержки.  Каждый репозиторий — это своя
экосистема, и выбор дистрибуции программного обеспечения в виде пакетов
в дистрибутивах Линукс, и пакета как минимальной единицей такой
дистрибуции, был сделан в том числе с учётом удобства поддержки такого
решения.

Другое дело, что действительно есть необходимость использовать
программное обеспечение, использующее модули какой-то языковой
экосистемы, и нужно упростить процесс опакечивания таких модулей.
Например, какой-нибудь инструмент, который тянул бы с апстримного
репозитория исходники, создавал бы gear-репозиторий и первое приближение
спека, например, на основе правил сборки этого пакета в родном
репозитории. И для сборки из данной языковой экосистемы написать
генераторы зависимостей и набор тестов для проверки их
работоспособности.  При этом хотелось иметь возможность в будущем
удостовериться, что стянутые исходники действительно соответствуют
указанному срезу версии. И, разумеется, в этом случае не надо собирать
весь репозиторий подряд, а только то, что действительно нужно.

И это немаленький объём работы, и если есть заинтересованные в
какой-либо определённой языковой экосистеме, чтобы собирать в Сизиф
пакеты с её использованием, то лучше начинать инициативу в devel@'а по
созданию инфраструктуры по интеграции её в Сизиф (оформление политик
сборки, создания инструментов импорта модулей в первом приближении,
генераторов зависимостей, проверок корректности загружаемости и др).

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