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

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

[Eugene Prokopiev]

3 марта 2018 г., 16:02 Igor Vlasenko написал:

> ... ранее
> большинство языковых экосистем у нас были представлены
> только базовым компилятором или интерпретатором и ограниченным набором
> основных библиотек. На самом деле такая ситуация не очень
> хороша. Это как дать пользователю базовую систему
> (ядро+shell+cc) и сказать, а дальше собирайте сами.
> Тем не менее, большинство предпочтет полноценный дистрибутив

Вот в этом месте ошибка. Большинство предпочтет тот способ, который
рекомендует апстрим. Апстримы рекомендуют maven/gradle, npm/yarn,
rubygems, cpan и прочие pip/virtualenv для библиотек, а еще
sdkman/nvm/rvm и т.д. для выбора рантайма

Разумеется, этот способ плох: мы тянем артефакты из чужого репозитария
(а там свои тараканы), вдобавок некоторые еще и компилируем. Но у
этого способа есть критически важное преимущество - он работает.
Тысячи пакетов к любой языковой экосистеме в Сизифе не работают, а
просто лежат мертвым грузом (хорошо, не к любой, но к актуальным для
меня java и python, возможно в случае ocaml или texlive все иначе).
Как только дело доходит до запуска прикладного ПО, которое умеет
делать что-то полезное (от eclipse до webvirtmgr или собственно
packages.altlinux.org :) ) - увы :(

Для большинства полноценная поддержка языковых подсистем - это (в
порядке убывания значимости):

1) актуальная версия компилятора/интерпретатора и прочих инструментов в Сизифе
2) работающая возможность установки библиотек рекомендуемым апстримом
способом (т.е. не из Сизифа)
3) опакеченное в Сизиф популярное прикладное ПО на этом языке
4) возможность пользоваться Сизифом вместо родного для этого языка репозитария

Да, еще (0) - возможность поставить хотя бы официальный пакет с сайта
апстрима, если в Сизифе версия (как оно часто бывает) протухла ...

Все это прямо таки взывает к призраку старой идеи о разделении Сизифа
на компоненты. Даже формулировка полиси напрашивается: языковая
экосистема может появиться в базовой части Сизифе тогда и только
тогда, когда она в состоянии обеспечить сборку и поддержку
необходимого для базовой части прикладного ПО на своем языке (в объеме
не большем, чем необходимо для этого самого прикладного ПО), иначе она
должна быть удалена из Сизифа. perl/python/lua похоже, проходят ценз,
java/ruby/ocaml/nodejs/texlive с высокой вероятностью вылетают в
дополнительные компоненты, в совсем отдельные компоненты вылетают
тысячи импортированных библиотек, ценность которых стремится к нулю
(потому что пользователю компонента java с высокой вероятностью не
потребуются тысячи java-библиотек) ...

Может большая часть обсуждаемых проблем сборочницы - это проблема
отсутствия компонентов (не обязательно привязанных к языковым
экосистемам, они просто под руку подвернулись)?

> Но сейчас ALTLinux вырастает из детских штанишек,

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

-- 
WBR,
Eugene Prokopiev

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

[Paul Wolneykien]

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) устанавливает *живой* контакт с другими репозиториями,
пакетными базами — становится узловой точкой, соединяющий дистрибутивы.

Re: [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@'а по
созданию инфраструктуры по интеграции её в Сизиф (оформление политик
сборки, создания инструментов импорта модулей в первом приближении,
генераторов зависимостей, проверок корректности загружаемости и др).

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

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

[Yury A. Romanov]

On 06.03.2018 12:43, 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_ репозиториями. Чтобы в спеке можно было написать
> что-то вроде:
> 
Есть ещё третий путь -- бутстрапить зависимости в приложение.
0. Самое ценное для репозитория дистрибутива в этих языках это 
приложения, на них написанные. К примеру, docker,vault, consul на go, 
redmine на RoR, какая-нибудь очередная ERP на Java
1. Приложений на языках с собственными экосистемами пишется много, но 
реально нужны из них единицы, все остальные приложения либо являются по 
факту узкоспециальными решениями, зачастую не совсем опенсорсными, либо 
либами, которые отдельно от приложений мало кому полезны.
2. Либы для языка, раскладывающиеся из пакетов это хорошо, но 
бесполезно, поскольку чаще всего современные "языки с экосистемами" 
генерят бинарники, не имеющие внешних зависимостей (не считая таковых 
уровня "нужна любая JRE версии 8" или "нужен glibc>=N" для приложений на 
go), то есть в рантайме им практически ничего не надо. Разработчикам 
приложений на сизифе (или любом другом дистро) эти либы тоже не особо 
нужны, поскольку это сразу же делает vendor-lock-in на сизиф, что было 
бы странно.

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


>    Requires: nmp::my-favorite-lib
> 
>    **IMHO** Первый путь — тупиковый, ибо в пределе Сизиф становится
> [мёртвой] копией всех пакетов в мире. Второй путь — перспективный, ибо в
> нём Сизиф (apt) устанавливает *живой* контакт с другими репозиториями,
> пакетными базами — становится узловой точкой, соединяющий дистрибутивы.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
> 

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

[Vitaly Lipatov]

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

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

[Igor Vlasenko]

On Mon, Mar 05, 2018 at 08:12:29PM +0300, Eugene Prokopiev wrote:
> Может большая часть обсуждаемых проблем сборочницы - это проблема
> отсутствия компонентов (не обязательно привязанных к языковым
> экосистемам, они просто под руку подвернулись)?

По теме компонент, это к сборочнице.
Но там проблемы:

1) ручной работы не должно быть, поэтому сборочнице нужно
указать алгоритм классификации, который мне лично не ясен - 
в какой собранный компонент пакет отправлять
и так, чтобы нигде не возникло unmets.

2) когда проясним алгоритм классификации,
он еще должен быть эффективным, не более 10 сек,
мы же не хотим, чтобы сборочница тормозила.

По языковым экосистемам я отдельное письмо хочу написать,
только там подумать надо, хочу взять паузу.


-- 

I V

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

[Андрей Бергман]

Ну в данном случае надо разделять пользователя и разработчика.
Мало кто всё-таки склонен таскать всё-с-собой windows-style для
каждого пользователя отдельно. Каждый пользователь Sisyphus'а
 в основном пользователь всех этих языковых систем, и изредка - 
разработчик какой-то одной, ну двух.

У части систем есть lts релизы - texlive, stack (Haskell), opam switch (Ocaml).
Т.е. можно засовывать в компонентный репозитарий Sisyphus именно этот
lts релиз. Это, конечно, не cutting-edge, но вполне разумно-свежий сборник,
подпиленный мейнтейнерами языкового репозитария.

Некоторая проблема возникает в том, что часть этих экосистем
требуют общих библиотек (binding'и). И эти библиотеки могут конфликтовать.
Гипотетический пример: GSL старой версии требуется для последней версии OPAM'а,
а для Python'а уже нужна самая свежая версия GSL.

Т.е., возможно, придётся реализовывать механизм альтернатив по
общим библиотекам.

Кроме того, языковые репозитарии "дышат" - у них меняются внутренние
зависимости, какие-то пакеты уходят в deprecated и поэтому должны быть
удалены из Sisyphusa автоматом.

Вообще, правильное подключение языковых репозитариев, насколько я
понимаю, не решено нигде.

Андрей.

05.03.2018, 20:12, "Eugene Prokopiev" <enp@itx.ru>:
> 3 марта 2018 г., 16:02 Igor Vlasenko написал:
>
>>  ... ранее
>>  большинство языковых экосистем у нас были представлены
>>  только базовым компилятором или интерпретатором и ограниченным набором
>>  основных библиотек. На самом деле такая ситуация не очень
>>  хороша. Это как дать пользователю базовую систему
>>  (ядро+shell+cc) и сказать, а дальше собирайте сами.
>>  Тем не менее, большинство предпочтет полноценный дистрибутив
>
> Вот в этом месте ошибка. Большинство предпочтет тот способ, который
> рекомендует апстрим. Апстримы рекомендуют maven/gradle, npm/yarn,
> rubygems, cpan и прочие pip/virtualenv для библиотек, а еще
> sdkman/nvm/rvm и т.д. для выбора рантайма
>
> Разумеется, этот способ плох: мы тянем артефакты из чужого репозитария
> (а там свои тараканы), вдобавок некоторые еще и компилируем. Но у
> этого способа есть критически важное преимущество - он работает.
> Тысячи пакетов к любой языковой экосистеме в Сизифе не работают, а
> просто лежат мертвым грузом (хорошо, не к любой, но к актуальным для
> меня java и python, возможно в случае ocaml или texlive все иначе).
> Как только дело доходит до запуска прикладного ПО, которое умеет
> делать что-то полезное (от eclipse до webvirtmgr или собственно
> packages.altlinux.org :) ) - увы :(
>
> Для большинства полноценная поддержка языковых подсистем - это (в
> порядке убывания значимости):
>
> 1) актуальная версия компилятора/интерпретатора и прочих инструментов в Сизифе
> 2) работающая возможность установки библиотек рекомендуемым апстримом
> способом (т.е. не из Сизифа)
> 3) опакеченное в Сизиф популярное прикладное ПО на этом языке
> 4) возможность пользоваться Сизифом вместо родного для этого языка репозитария
>
> Да, еще (0) - возможность поставить хотя бы официальный пакет с сайта
> апстрима, если в Сизифе версия (как оно часто бывает) протухла ...
>
> Все это прямо таки взывает к призраку старой идеи о разделении Сизифа
> на компоненты. Даже формулировка полиси напрашивается: языковая
> экосистема может появиться в базовой части Сизифе тогда и только
> тогда, когда она в состоянии обеспечить сборку и поддержку
> необходимого для базовой части прикладного ПО на своем языке (в объеме
> не большем, чем необходимо для этого самого прикладного ПО), иначе она
> должна быть удалена из Сизифа. perl/python/lua похоже, проходят ценз,
> java/ruby/ocaml/nodejs/texlive с высокой вероятностью вылетают в
> дополнительные компоненты, в совсем отдельные компоненты вылетают
> тысячи импортированных библиотек, ценность которых стремится к нулю
> (потому что пользователю компонента java с высокой вероятностью не
> потребуются тысячи java-библиотек) ...
>
> Может большая часть обсуждаемых проблем сборочницы - это проблема
> отсутствия компонентов (не обязательно привязанных к языковым
> экосистемам, они просто под руку подвернулись)?
>
>>  Но сейчас ALTLinux вырастает из детских штанишек,
>
> Мне кажется, что сейчас мы больше обсуждаем автоматизацию смены
> памперсов ... Тоже полезное дело, однако рост выглядит иначе:
> упоминание ALT на апстримных страничках установки языковых экосистем
> как минимум и рекомендация там же использовать Сизиф уже как максимум.
>
> --
> WBR,
> Eugene Prokopiev
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel