[devel] Спасём python3 вместе!

[Grigory Ustinov <grenka@altlinux.org>]

Добрый день, уважаемые участники ALT Linux Team.

Прошло уже почти два года с момента опубликования статьи:

https://www.altlinux.org/Management_of_Python_dependencies_sources

В тихую, без анонсов и обсуждения в списках рассылок, был введён такой 
подход к сборке питоновских пакетов. Планомерно и методично, группа лиц, 
разделяющих симпатию к этому подходу переводила сначала свои пакеты на 
эту схему, а потом начала тянуться к общим и даже чужим. План 
вышеуказанных участников был в том, чтобы привести в такой вид 
максимальное количество пакетов и сдвинуть окно овертона. Если чего-то 
большинство, значит оно не может быть плохим. Сейчас количество таких 
пакетов перевалило уже за полтысячи и достигло критического количества. 
Пора решать проблему.

Эмоции в сторону, давайте сосредоточимся на проблемах этого подхода:

1.) Данный подход полностью ломает идею спек-файла, который по 
оригинальной задумке должен хранить _всю_ информацию о пакете. То есть 
открыв спек-файл нельзя определить его зависимости, в поиске по спекам 
нельзя отгрепать зависимости и так далее.

2.) Спек превращается в результат автогенерации бесчисленного количества 
макросов. Раньше подобным автогенератам было место в репозитории 
Autoimports, в сизиф же пропускались "очеловеченные" спеки, которые 
доступны для чтения и понимания участникам сообщества. Перефразируя 
Мартина Фаулера "Скрипты могут писать спеки, понятные сборочнице, 
хорошие мейнтейнеры пишут спеки понятные людям".

3.) Проблемы с бэкпортами. Вспоминаем сколько спотыкались о другую 
"инновационную разработку" под названием ubt.

4.) Автоматическая генерация зависимостей очевидно порождает мусор. 
Поэтому в 180 пакетах из 560 присутствуют костыли под названием 
*_filter, которые призваны отфильтровывать список зависимостей. То есть 
вместо списка зависимостей, в спеке идёт список _независимостей_.
Вот как это выглядит: 
https://packages.altlinux.org/ru/sisyphus/srpms/python3-module-isort/specfiles/

Как минимум 75 пакетов собранных с этими автоматическими зависимостями 
этого механизма абсолютно не требуют, поскольку нуждаются всего в 3 
пакетах setuptools, wheel и pytest.

5.) В текущем состоянии наш замечательный репозиторий сизифа потерял 
консистентность в области питоновских пакетов. Очевидно, что для 
обновления или исправления одних пакетов зачастую приходится влезать в 
другие. Далеко не у всех есть желание разбираться в модулях собранных 
этим необычным способом. Так, например, за последний год было 
_испорчено_ несколько ключевых модулей, для бутстрапа нового питона. 
Ручки бутстрапа оторваны, списки зависимостей переделаны в 
автоматическом режиме, хотя раньше всё было чётко выверено.


Я предлагаю всем заинтересованным против принятия этой технологии лицам 
высказаться в этом треде. Со своей стороны могу предложить помощь в 
устранении последствий этого "эксперимента". 75 пакетов чинятся 
элементарным скриптом, для других готов попробовать придумать скрипт 
посложнее.

Автору данного подхода рекомендую доделать свою автоматику таким 
образом, чтобы ей можно было пользоваться добровольно. То есть написать 
скрипт таким образом, чтобы он из существующих файлов со спецификациями 
зависимостей выдирал всё необходимое как сейчас, но добавлял их не в 
отдельный json-файл а в привычном для всех виде как BuildRequires в 
спек-файле. Я такое уже реализовывал для обновления библиотек openstack.