Re: [devel] python3.x(qwe) vs python3(qwe)

[Alexey Morozov <morozov@altlinux.org>]

В сообщении от Вторник 02 февраля 2010 12:06:56 автор Andrey Rahmatullin 
написал:
> On Mon, Feb 01, 2010 at 12:03:14AM +0600, Alexey Morozov wrote:
> > Тогда надо кардинально менять схему упаковки. В своём нынешнем виде и
> > заявленных целях (кстати, если не секрет, есть где-нибудь место, где эти
> > цели явно проартикулированны?)
> 
> Только не говори, что ты не имеешь отношения к нашему Python Policy.

Оно прокисло и как минимум в одном важном пункте не соблюдается. Так что, 
можно считать его практически несущественным, хотя, _возможно_ , и интересным 
с исторической точки зрения.

На мой взгляд, основная проблема нынешней схемы:

с одной стороны, используются механизмы привязывания модуля к определённой 
версии при сборке пакета (собственно, для большинства модулей эти механизмы 
вытекают из схемы их расположения, %_libdir/pythonX.Y, а для меньшей части - 
из привязок к libpython). При этом, замечу, основная цель выбранного 
расположения, - борьба с несовместимостями между версиями и архитектурами в 
питоньем байткоде, - выглядит для меня достаточно умозрительной here and now.

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

Как из этого выходить? Фиг знает. Можно, например, отказаться от принципа 
"инсталлируется apt'ом - значит работоспособно" (да-да, я знаю, что это плохо 
:) ). 

Кстати, вероятнее всего, 90-ста процентам тех пакетов, которые используют 
питон в качестве языка скриптования, совсем необязателен "полноценный питон" 
со сколько-нибудь полной библиотекой, достаточно libpython. Соответственно, 
масштаб революции в репозитории можно будет сильно уменьшить, если в момент 
заливки нового питона предоставлять libpython-compat для уходящей версии.

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

Дебиановцы, повторюсь, пошли по третьему пути. source-level пакеты 
распространяются в виде .py, которые при инсталляции раскладываются вместе со 
сгенерёнными тут же .pyc в каталоги, соответствующие установленным на 
конкретной машине версиям python'а. Отдельно решается вопрос с архитектурно-
зависимыми, "бинарными" пакетами.

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

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

АМ