[devel] I: python 3 copycat robot

[George V. Kouryachy]

On Thu, May 23, 2013 at 10:58:51AM +0300, Igor Vlasenko wrote:
> Господа,
> у нас с модулями для 3-го питона ситуация плохая -
> собрано около 10% модулей по сравнению с 2-м питоном,
> 
> Робот берет пакет модуля для 2-го питона,
> проверяет, нет ли уже в нем (отключенного)
> модуля для 3-го питона, как это например есть в 
> python-module-PyQt4, и если нет,
> то трансформирует этот пакет в новый пакет, 
> который уже соберет модуль для 3-го питона.
...
> Нет возражений для развертывания робота
> Python 3 copycat в Сизиф?

Возражение ниже, сначала попробую описать ситуацию, как я её вижу.

Необходимо решить три задачи:

1. Унифицировать подмножества rpm-макросов. Сейчас макросы второго
   и третьего питона резко отличаются, в третьем многих не хватает.
2. Как-то обустроить ситуацию, при которой модуль для третьего питона
   получается из исходников не напрямую, а с помощью 2to3, мелкого
   ручного дохакивания по месту и т. п.
3. Как-то обустроить ситуацию, когда модули для второго и для третьего
   питона при этом ещё и принципиально различаются (например, составом).
   Это нас ожидает в полной мере, потому что (поправьте, если ошибаюсь)
   ни PyGTK, ни wxPython пока для Python3 не существуют, ну и другие.

Кстати, пресловутый python-module-enchant иллюстрирует две проблемы из трёх,
равно как и метод, которым мне хочется собирать двухпитоновые пакеты --
specsubst. Просьба на ужасающее использование %ifdef setup_python_module
не ругаться: это сделано намеренно, чтобы пакет сломался, когда макросы
починим :). См. сюда:
http://git.altlinux.org/people/george/packages/?p=python-module-enchant.git;a=blob;f=python-module-enchant.spec

Пока это выглядит мерзковато, но идея в том, чтобы вынести specsubst
в один базовый макрос, а все остальные будут раскрываться в python2
и python3 соответственно.

А теперь полтора возражения.

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

Но. До тех пор, пока не будут как-то решены три указанные проблемы,
полученный генератом спек будет или ужасен, или неполноценен.

И сопровождение python3-пакета наличием автосборки будет не упрощаться,
а (потенциально) усложняться, т. к. автосборка начнёт заджавать легаси.

И, кстати,
http://packages.altlinux.org/en/Sisyphus/srpms/python3-module-enchant/repocop

Что не так с __pycache__/*.pyo? Они действительно платформо-зависимые?
Или это баг репокопа?

-- 
				  Георгий Владимирович Курячий
				  Эксперт компании "Альт Линукс"
				  Mailto/JID: george на altlinux.org
				  Mobile: (8)9161738325