[devel] ruby модули

[Igor Zubkov]

2011/3/28 Andrew V. Stepanov:
> Добрый день.
>
> У кого есть аргументы против того чтобы ликвидировать все ruby модули
> из Sisyphus ?
>
> У меня есть следующие доводы чтобы это сделать:
>
> 1. Каждый проект основанный на ruby имеет свои требования к окружению
> начиная от версия модулей, заканчивая самим интерпретатором.
>
>  * теже рельсы бывают:  2.3.x и 3.0

Это ещё не все версии рельс которые могут понадобится. Просто это две
ветки поддерживаются в текущий момент.

>  * разные интерпретаторы: ree, rubinius, jruby, ironruby

Все эти интерпретаторы кроме ree просто экзотика. REE обычно
используется в тяжёлых сайтах под капотом. Даже наш
http://packages.altlinux.org использует его.

>  * версии интерпретаторов: 1.8.7, 1.9.1, 1.9.2

1.9.1 умер. Пора про него забыть.

> собирая что одно мы покрываем только маленькую часть действующих
> проектов, если вообще что-то покрываем.

В текущий момент покрывается только одна задача, это redmine из
дистрибутива (ну или коробки). Больше ни для чего (сайто-хостинга) оно
не годится.

> 2. Модули довольно быстро устаревают для сизифа, и невозможно собрать
> универсальных модулей которые бы подходили для всех проектов.

Если эти gems можно поставить через rubygems и они будут работать, то
наличии их в дистрибутиве под вопросом. Зачем поддерживать его у нас
(тратя время и силы) если можно поставить из rubygems.

> 3. Rubу сообщество настойчиво предлагает использовать gems со своим
> ведением зависимостей.
>  А также:
> * bundler ( включен в rails 3.0 )

Вот bundler надо давно упаковать с Сизиф.

> * rvm - Ruby Version Manager

RVM это скорее больше для разработки нужен чем для всего остального.

> 4. Другие дистрибутивы не собирают все подряд модули ruby себе в репозиторий.
>
> Минусы:
>
> Мы теряем красоту при сборке native-модулей, которые собираются из .c
> .cc и требуют наличие gcc-c++  & devel пакетов.

gcc и devel пакеты можно потом и удалить. Или вообще собирать пакеты в
hasher на соседней машине с компилятором.

В идельном случае, я вижу ситуацию так:
1) у нас два ruby: ree & 1.9.2
2) на альтернативах
3) рабочий rubygems который позволяет ставить gems в систему
4) и ставить эти gems не в /usr/lib/ruby а в что-то типа /var/...
5) bundler из коробки
6) если у нас будет ree в дистрибутиве, то тогда уж и passenger надо
бы добавить (тогда можно будет перенести packages.a.o на
дистрибутивный ruby/passenger/nginx)

Это по части веб технологий и руби. Тут есть ещё десктопная часть. Я
думаю что она должна выглядеть так:
1) мы собираем только нужные джемы нужных версий
2) под 1.9.2 ruby
3) зависимость на rubygems запрещена

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

-- 
Igor Zubkov
http://hi.im/ice