[devel] Зависимости ruby-libs и libruby и новая политика 2.0

[Ivan A. Melnikov]

On Tue, Feb 12, 2019 at 09:44:37AM +0300, Andrey Cherepanov wrote:
> 11.02.2019 22:50, Michael Shigorin пишет:
> > On Mon, Feb 11, 2019 at 05:27:18PM +0300, Скрылевъ Малъ wrote:
> >> Потому для такой схемы следует не определять зависимости
> >> автоматически, а вписывать их руками, есть также вариант просто
> >> сочинить нужные Gemfile-ы, хотя в этом проекте они есть.
> > Пойми одну простую вещь: для внешнего наблюдателя это чистой воды
> > регрессия.  Было, работало, сломали.  Ради чего?
> 
> Миша, ты собирал сотни пакетов на Ruby, чтобы делать такой вывод?

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

> Ты собирал сам Ruby? Ты сможешь прокомментировать причины отказа от
> старой схемы? Ты моделировал поведение разработчика на Ruby?

К сожелению люди, которые всё это проделали, не сочли нужным
поделиться своим анализом с сообществом. Напоминать при этом
про действующую https://www.altlinux.org/Policy_Policy
кажется уже почти бестактным.

В Ruby Policy 2.0 этого анализа тоже нет, а обоснование
изменений сводится к довольно короткому подразделу
"Сравнение с предыдущей политикою". Кстати, в нём я
совершенно не распарсил грамматику в половине пунктов,
особенно в этом:

| для Gemfile проектов потому, что вызовы require являются
| неявными и выполняются bundler-ом опосредованно на основе
| анализа Gemfile и .gemspec если таковой присутствует. также
| bundler следит за тем, чтобы среда и окружение разработки
| таких проектов были целостными, это приводит к том, что
| вызов require к внешнему модулю при необъявленная
| зависимость на него в Gemfile, приведет к критическому
| затруднения разработки проекта;

В общем, ответ на предъявленный выше вопрос "Ради чего?" я
могу только попробовать угадать.

Также, пункт "Правила перехода на схему сию" описывает 
только переход для пакетов, представляющих собой запаковыные
gem'ы. Как мы выяснили, не все ruby-пакеты таковы, однако
последствия и способы исправления этих последствий для
прочих пакетов не описаны.

Случай opennebula показывает, что в Сизифе появился новый
класс сломаных пакетов -- пакеты, потерявшие нужные им
зависимости из-за перехода на новую схему поиска
зависимостей в ruby. Этот случай также не описан в политике.
Также по всей видимости масштабы проблемы остаются
неизвестными.

--
  wbr,
    iv m.