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

[devel] 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 --]

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

[Andrey Orlov]

On Sunday 11 January 2004 06:28, Alexey Morozov wrote:
> Грустно. Почему - ниже.
> > Старые версии питона, типа python22 остаются
> > исключительно для целей разработки и тестирования, соответственно,
> > предполагается что те, кому они нужны - в состоянии пересобрать все
> Не понятно, зачем тогда держать такой пакет, если пользоваться им все равно
> нельзя.

Я уже объяснил. Для разработчиков. Сплит на две альтернативы произошел до моего
появления в AltLinuxTeam и я точно не знаю чем он был вызван. Предположительно -
тем, что Zope не работал с python22. С моим появлением ситуацию с Zope мы разрулили
и по большому счету pythob21 стал не нужен. Но, как у мантейнера Zope, у меня
иной раз возникала в нем необходимость. Просто чбы убедится в том, что некая бага
не привнесена переносом Zope на python22, а воспроизводится на python21.

С официальным переходом Zope на python223 пакет python21 стал не нужен. Сейчас
ситуация повторяется с python22 / 23. 

> Тогда логичнее было бы делать так:
>
> python-<the last and shining version>
> python-compat<any previous version>

Оно сделано так как сделано. Считайте, что это осталоь так по историческим причинам.

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

Тогда вы получите тоже самое что сейчас, только с другой стороны - у вас отвалятся
MySQLdb, psycopg etc. Таким образом, вы опять не будете иметь полного набора
пакетов для обеих версий питона. Я все это уже видел на 21 vs 22. 

Вы все-таки киньте мне на мыло посмотреть ваши макросы и т.п. Если бы я был 100% 
уверен в том, что это невозможно и ненужно - я бы даже обсуждать это не стал ;).

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

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

> > Как тогда это соотносится с:
> > положу 2.6.3 в сиз (завтра, наверно) кто им пользуется - будьте

Вышеупомянутым образом. Разработчики Z портировали его на py23, причем заявлено
что ближайшие версии Z будут несвместимы с py22 в любых проявлениях. 

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

Да. Я с этим согласен. Но, как я уже сказал - для перехода на python23 был 1 (один) год.
Времени достаточно. Для дальнейшей поддержки заказчиков есть дистрибутив
master 22 который можно им ставить. В ALM3, вполне возможно, python22 не будет.
Во всяком случае  - мой голос "ЗА".

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

Любой апдейт из Сизифа - это уже кардинальное изменение положения. В то же
время, по опыту патчей к Zope, за редчайшим исключением, переход py21 - py22 и
py22 - py23 не есть кардинальное изменение положения. 

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

Я вас очень хорошо понимаю. Я прохожу через это каждое лето. В тех случаях, когда
оплата перехода оказывается невозможной - я не апдейчу клиентские сервера до
нового мастера, а ограничиваюсь паккетами из updates. Соответственно, новый софт
клиент не получает и это логично: за новые версии надо платить.

Но всю разработку мы ведем только на последних версиях, соотв. если наш старый
клиент хочет новые фичи, которых не было в старых версиях софта - ему приходится
ставить новую версию и нашего софта, и его окружения. И, по факту, я не в силах
поддерживать в  новых версиях продуктов ни совместимость с python21 / 22, ни 
совместимость с Zope251, ни совместимость с omniORB3: просто не было в них тех
возможностей, которые используют новые версии наших продуктов. И это вполне
естественно. Так что, мое мнение:

 1. Сизифус - для разработчиков, для которых актуален немедленный переход на новые версии
     софта;

 2. Поддержка старых инсталляций осуществляется исключительно за счет updates старых
      дистрибутивов, а не за счет апдейта из сизифа;

 3. Обновление старых инсталляций в связи с переходом на новые версии софта требует
     перехода на послендий оффициальный релиз дистрибутива.

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

ЗЫ: Когда я закончил институт и делал свой первый проект, я не придерживался первого
пункта и наступил на очень большие грабли: к моменту сдачи проекта весь софт, на
котором он был построен безнадежно устарел.  С его сдачей возникли проблемы... Теперь
для меня разработка на последних релизах, а лучше даже на альфа- и бета- версиях - непреложное
правило от которого я стараюсь не отходить и другим советую тоже самое.

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

Re: [devel] Re: [sisyphus] ðÉÔÏÎØÉ ÍÏÄÕÌÑ

[Alex Ott]

Привет

>>>>> "AO" == Andrey Orlov writes:
 AO> ЗЫ: Когда я закончил институт и делал свой первый проект, я не
 AO> придерживался первого пункта и наступил на очень большие грабли: к
 AO> моменту сдачи проекта весь софт, на котором он был построен безнадежно
 AO> устарел.  С его сдачей возникли проблемы... Теперь для меня разработка
 AO> на последних релизах, а лучше даже на альфа- и бета- версиях -
 AO> непреложное правило от которого я стараюсь не отходить и другим
 AO> советую тоже самое.

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

-- 
With best wishes, Alex Ott
-------------------------------
Jet Infosystems, Moscow, Russia    mailto: ottalex@narod.ru
http://xtalk.msk.su/~ott/          ICQ #22005116

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

[Andrey Orlov]

On Sunday 11 January 2004 22:23, Alex Ott wrote:
>  AO> устарел.  С его сдачей возникли проблемы... Теперь для меня разработка
>  AO> на последних релизах, а лучше даже на альфа- и бета- версиях -
>  AO> непреложное правило от которого я стараюсь не отходить и другим
>  AO> советую тоже самое.
>
> По моему опыту, житье на альфа-бета версиях очень часто чревато
> дополнительной работой, за счет неустойчивости интерфейсов и т.п. Да и
> когда разрабатываешь софт не только для одного дистрибутива, а для пачки
> линуксов и других юниксов, то тащить за собой кучу лишнего софта или
> требовать от заказчика обновления его системы - не всегда приемлимо.


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

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