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

[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