[sisyphus] Питоньи модуля

[sisyphus] Питоньи модуля

[Alexey Morozov]

Вопрос: а не следует ли договориться о единой схеме наименования и
построения питоньих модулей в Сизифе?

По поводу наименования у меня следующие предложения.

Во-первых, именовать их по тому же принципу, по которому именуются
модули perl: perl-SMTH.

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

В итоге имеем:

python22-ZSI-1.4.1-alt2.i586.rpm
python23-ZSI-1.4.1-alt2.i586.rpm

По поводу построения, я нацарапал нечто, что собирает из одного src.rpm
(python-ZSI-1.4.1-alt2.src.rpm) один или два бинарных модуля, в
зависимости от опций сборки: --with python_auto (default, берется
текущая по альтернативам версия питона), --with python22, --with
python23. В принципе, наверное, то, что у меня есть, можно причесать,
унеся общие для всех модулей куски в /etc/rpm/macros.d/ или куда-нибудь
еще.

Комментарии?

Re: [sisyphus] Питоньи модуля

[Алексей Любимов]

Тоже хотел поднять этот вопрос.

По моему, именно так и надо делать.

Вопрос, вынесет ли это сизиф и майнтейнер. питона с модулями.


Alexey Morozov пишет:

>Вопрос: а не следует ли договориться о единой схеме наименования и
>построения питоньих модулей в Сизифе?
>
>По поводу наименования у меня следующие предложения.
>
>Во-первых, именовать их по тому же принципу, по которому именуются
>модули perl: perl-SMTH.
>
>Во-вторых, коль скоро у нас одновременно болтаются две и более версии
>питона, причем, модули для них тоже нужно собирать отдельно, то в имя
>пакета вносится и версия питона.
>
>В итоге имеем:
>
>python22-ZSI-1.4.1-alt2.i586.rpm
>python23-ZSI-1.4.1-alt2.i586.rpm
>  
>

А посмотреть на нацарапанное?

>По поводу построения, я нацарапал нечто, что собирает из одного src.rpm
>(python-ZSI-1.4.1-alt2.src.rpm) один или два бинарных модуля, в
>зависимости от опций сборки: --with python_auto (default, берется
>текущая по альтернативам версия питона), --with python22, --with
>python23. В принципе, наверное, то, что у меня есть, можно причесать,
>унеся общие для всех модулей куски в /etc/rpm/macros.d/ или куда-нибудь
>еще.
>
>Комментарии?
>
>_______________________________________________
>Sisyphus mailing list
>Sisyphus@altlinux.ru
>http://altlinux.ru/mailman/listinfo/sisyphus
>  
>

Re: [sisyphus] Питоньи модуля

[Alexey Morozov]

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

On Fri, Jan 09, 2004 at 07:41:24PM +0300, Алексей Любимов wrote:
> >В итоге имеем:
> >
> >python22-ZSI-1.4.1-alt2.i586.rpm
> >python23-ZSI-1.4.1-alt2.i586.rpm
> А посмотреть на нацарапанное?
Соберу на Мише, отдам в Сизиф.
В принципе, конечно, можно и на idisys'е выложить...


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Питоньи модуля

[Andrey Orlov]

Hi!

Если кратко - проблема поставлена интересная, но конкретно
к ситуации с питоном такой подход излишен. Далее подробно.

On Friday 09 January 2004 18:36, Alexey Morozov wrote:
> Во-вторых, коль скоро у нас одновременно болтаются две и более версии
> питона, причем, модули для них тоже нужно собирать отдельно, то в имя
> пакета вносится и версия питона.

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

Затачивать дистрибутив под две версии питона, устанавливаемые по выбору, я не вижу
необходимости - это все-таки не emacs-nox vs emacs-X11, которые имеют не пересекающиеся
возможности, в данном случае python23 полностью перекрывает python22, аналогичная
ситуация была и с python21 vs python22.

> По поводу построения, я нацарапал нечто, что собирает из одного src.rpm
> (python-ZSI-1.4.1-alt2.src.rpm) один или два бинарных модуля, в

Надо будет посмотреть. Но, вообще гря, Zope пропатченный и собранный для python22
иногда не собирался с python21. Точнее, собирался но не работал. То же самое - MySQLdb.
Кроме того, зачастую новые версии пакетов затачиваются исключительно под новую версию
python и перестают пересобираться со старыми версиями, в них так и пишут "required". Таким
образом, пересобрать новую версию пакета под оба питона  сразу - в общем случе, нереально. 
Тем более автоматически. Надо либо откатываться на старую версию, либо делать бакпорт.

> Комментарии?

Излишне: затраты времени на поддержку не окупятся иллюзорным выигрышем, который
для пользователя морально-устаревшего компилятора (интерпретатора) очень быстро 
грозит обернутся  проигрышем. Исключения бывают - типа двух gcc в нашем дистрибутиве -
но, насколько я понимаю, дублирования пакетов там не происходит - софт разбит на две группы,
каждая из которых собирается своим компилятором.  Если бы с питоном была 
аналогичная проблема (например, Zope работающий исключительно с py21) - я бы с вами 
согласился. Но, такой проблемы нет.

Подводя итог: Наиболее предпочтительный вариант - иметь только последний питон.
Т.е. я бы python22 вообще выкинул. Но для тестирования - полезно. Все свои проекты и
продукты я перевел на 23 и вам советую сделать тоже самое (все-таки на это был почти год
времени). На самом деле, на сегодняшний день я не вижу ни одной реальной потребности 
пользоваться устаревшим интерпретатором. Даже Zope, при всей любви его разработчиков 
к реликтовому софту, начиная с версии 2.6.3 пропатчен ими до python23. Кстати, я скоро 
положу 2.6.3 в сиз (завтра, наверно) кто им пользуется - будьте поосторожнее. В отличие
от моих патчей на Z2.6.2, патчи от разработчиков изменили API некоторых продуктов (
особенно в области секьюрити). Хотя эти изменения можно считать "правильными", но
при переходе можно осыпатся.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

Re: [devel] Re: [sisyphus] Питоньи модуля

[Alexey Morozov]

[-- Attachment #1: Type: text/plain, Size: 3798 bytes --]

On Sat, Jan 10, 2004 at 02:58:19PM +0300, Andrey Orlov wrote:
> Были у мня такие идеи, но я пришел к мнению, что это излишне. Все пакеты 
> нужно портировать на последнию версию питона, пакетов собранные 
> под старые версии не держать.
Грустно. Почему - ниже.

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

> Затачивать дистрибутив под две версии питона, устанавливаемые по выбору,
> я не вижу необходимости - это все-таки не emacs-nox vs emacs-X11, которые
> имеют не пересекающиеся возможности, в данном случае python23 полностью
> перекрывает python22, аналогичная ситуация была и с python21 vs python22.
Тогда логичнее было бы делать так:

python-<the last and shining version>
python-compat<any previous version>

Или вообще отказаться от -compat, как таковых. Заливать всю байду (питон
и third-party модуля) разом при апдейте сизифиа и дело с концом.

Но опять же, см. возражения ниже.

> Надо будет посмотреть. Но, вообще гря, Zope пропатченный и собранный для
> python22 иногда не собирался с python21. Точнее, собирался но не работал.
> То же самое - MySQLdb.

> Кроме того, зачастую новые версии пакетов затачиваются исключительно под
> новую версию python и перестают пересобираться со старыми версиями, в них
> так и пишут "required". Таким образом, пересобрать новую версию пакета под
> оба питона  сразу - в общем случе, нереально. 
%define _with_python<bad version> --without-python<bad version>
прямо в спеке?

> каждая из которых собирается своим компилятором.  Если бы с питоном была 
> аналогичная проблема (например, Zope работающий исключительно с py21) -
> я бы с вами  согласился. Но, такой проблемы нет.
То есть, Вы утверждаете, что обратная совместимость есть всегда, и ситуация,
когда я при апгрейде питона и всех модулей получаю неработоспособное
приложения, невозможна, или, во всяком случае, _крайне_ мало вероятна?

Нет, мне это на самом деле крайне интересно знать.

Как тогда это соотносится с:

> положу 2.6.3 в сиз (завтра, наверно) кто им пользуется - будьте
> поосторожнее. В отличие от моих патчей на Z2.6.2, патчи от разработчиков
> изменили API некоторых продуктов (особенно в области секьюрити). Хотя эти
> изменения можно считать "правильными", но при переходе можно осыпатся.

Тут проблема очень простая, на самом деле. По своему предыдущему (непитоньему)
опыту я знаю, что у каждого продукта, если это не наколенный скрипт для
внутреннего потребления, есть maintaince cycle. То есть, грубо говоря, период,
когда мы _вынуждены_ поддерживать ту версию программы, которую установили
заказчику. Причем, поддерживать именно в том виде, в котором установили -
максимум, мелкие патчи, которые не меняют приложение кардинально.

Соответственно, каждое релиз, во-первых, четко позиционируется в дереве
исходников (ну, у нас это таг+бранч в CVS'е + полиси на то, что можно с
этим релизом делать, а что нельзя), а во-вторых, возможность воссоздания
сборочной среды, чтобы не было неожиданностей. Для всяких монструозностей
типа ACE/TAO это было более чем актуально, поскольку совместимости ни взад,
ни вперед никто не обещал.

Вопрос в том, насколько подобная довольно жесткая политика актуальна для
питона и приложений на нем. У меня довольно мало практического опыта его
использования.

У меня сейчас, возможно, образуется ситуация, когда я буду просто не в
состоянии говорить: "а мы с разработчиками тут переехали на новый [питон],
он рулит, но со старым [питоном] совместимости больше нет, и давайте мы вам
за _ваш_ счет произведём апгрейд". За свой, понятное дело, тоже не очень
хочется :-)). Вот и подпрыгиваю :-).


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]