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

[Alexey Morozov]

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 это было более чем актуально, поскольку совместимости ни взад,
ни вперед никто не обещал.

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

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

----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20040111/d7295351/attachment-0001.bin>