[devel] Сборка пакетов, содержащих .py

[Alexey Morozov]

On Fri, Jan 16, 2004 at 06:10:40PM +0300, Andrey Orlov wrote:
> On Friday 2004  January 16 13:50, Alexey Morozov wrote:
> > On Fri, Jan 16, 2004 at 10:12:43AM +0300, Andrey Orlov wrote:
> 
> > > Особенно автороство того, кто и что вам говорит? На этот вопрос
> > > отвечали, в разное время, два человека - я & Максим, и ответ был 
> совсем
> > > не такой.
> > Вопрос был другой :-)). И отвечали на него не Вы :-)
> Тогда почему вы приписали этот ответ мне? Вы сказали - один из 
> занимающихся сборкой python. Если верить changelog - Максим сборкой
> python не занимался, последние сборки python - мои. Мой же ответ был 
> другой, и так как мне влом искать его в pipermail, то я его повторяю 
> специально для вас еще раз:
Андрей, я написал: кто-то из команды. Поскольку я не помнил точно, и
искать, как Вы говорите, влом, то и указание получилось достаточно
расплывчатым. Чес-слово не хотел Вас задеть, не надо так реагировать.

> "Исходный код программ на питоне в общем случае не переносим при смене 
> 2.1 -> 2.2 -> 2.3. Это для меня _очень_ большая проблема, решением 
> которой на почве сервера приложений Zope я занимаюсь уже два года, и 
> об этой проблеме в свое время было написано не мало писем 
> русскоязычной питоновской рассылке."
Все понятно, я понял про исходный код, и хорошо, что в команде есть
человек, который плотно сталкивался с проблемами переносимости. У меня
такие проблемы, видимо, возникнут, и здорово будет обратиться к Вам за
поддержкой.

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

> Только что (см. патчи к Z262) пришлость устранять из Zope 
> несовместимости с новой версией python. Если вы загляните на сайт
> zope.org, то увидите, что половина changes в Zope263 посвящены именно 
> переносу его на python23.
Ну, если это _необходимость_, а не желание следовать веяниям времени, то
это грустно, на самом деле.

> 
> > /usr/lib/python2.2
> > /usr/share/python2.2
> > Кто прав, Максим или доки на питон, я не знаю, но это, в общем, в
> > контексте вопроса, обсуждаемого в _этом_ треде, и не важно.
> Скомпиленный питоновский модуль нельзя разместить с другим путем. Так
Но можно же задать при сборке собственно питона другое расположение
библиотечных путей, правда?

> как после этого он начинает немножко неправильно работать, (кажется, 
> в частности, выдавать неверную диагностику). Установлено это было еще 
> до моего прихода в команду, и кажется именно этим обусловлена 
> __двойная__ байт-компиляция всего питоновского кода. Подробнее об 
> этом может рассказать LDV если я правильно понимаю.
Ok, спросим LDV.

> Я еще раз вам говорю: такие зависимости есть. Самые заметные из них - 
> начиная с версии 23 питоновская программа не должна содержать 
> символов из второй половины кодовой таблицы или должна содержать 
> специальный заголовок с указанием кодировке. Без этого будет 
> выводится warning, вывод которого, в некоторых случаях, приводит к 
> нарушению работы скриптов и их окружения. Другие изменения, опять же 
> самыае заметные: None стало ключевым словом (половина Access* в Zope 
> отвалилась), модуль rotor был задеприкейчен - что опять же привело 
> к некислой правке того же Zope.
Андрей, я понимаю Вашу озабоченность проблемами сборки Zope. Но у меня
сейчас немного другие проблемы, не затрагивающие впрямую Zope. И я НЕ
претендую на универсальность моего решения.

> > Итого, сухой остаток:
> > 
> > Долой /usr/lib/rpm/brp-bytecompile_python!
> > Даешь /usr/lib/rpm/python.{req,prov}!
> Сухой остаток: я бы попросил ничего не менять, не разобравшись.
Именно это я и пытаюсь сделать.

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

во-первых, возможны нюансы, касающиеся переносимости собственно кода
(но на это хоть диагностика будет внятная),

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

В данном треде я совсем НЕ РАССМАТРИВАЛ первую проблему, целиком
занимаясь исключительно второй.
> Если вы считаете что _ваш_ пакет не должен содержать *pyc & *pyo - вы
> можете не _включать_ их в секцию files _вашего_ spec'а. А все
Могу. Но, во-первых, для модулей, все же, _хочется_ включать байткод,
причем, откомпилированный именно тем питоном, который потом будет этот
модуль использовать (сейчас это, по факту НЕ ТАК, если вместо %__python
используется, скажем, python-2.3). А во-вторых, мне, все же, больше
нравится оперировать списком файлов, сформированных на этапе

setup.py install

а не произвольными каталогами (хотя, возможно, это и относится к области
[неверных] личных предпочтений).

> глобальные изменения порядка комплиции стоит согласовывать со всеми.
Именно это я и делаю на протяжении последних нескольких писем.

> Пока что _лично_я_ против таких изменений, и  я хотя я согласен что 
> ситуацию с pyc & pyo надо менять - я против изъятия прекомпиляции как 
> таковой, так как наличие байткомпиляции является существенным 
> преимуществом питона перед, скажем, перлом.
Я не пытаюсь изъять байткомпиляцию. См. мои предыдущие письма в этом
треде относительно использования возможностей и данных distutils,
а не компиляции всего, что хоть отдаленно напоминает python.

> > Давайте жить дружно!
> Давайте, только прислушивайтесь к чужому мнению?
Как мне кажется, и так уже прислушиваюсь.

> На сегодняшний день оно такое:
> 
>  1. Перенос байт-кода из одной версии в другую не допустим;
Ура. Здесь мы с Вами едины во мнении.

>  2. Перенос исходного кода из одной версии в другую может приводить к 
> ошибкам, что отменяет возможность решения проблемы двух питонов за 
> счет отказа от прекомпиленного кода;
Нет. Это решение _другой_ проблемы. См. выше.

> 3. Сама проблема двух питонов является надуманной, так как никакой 
> необходимости держать два питона на одной машине я не знаю;
Андрей, выше Вы пишете о том, что при переезде с python-2.2 на
python-2.3 отвалилась большая часть Zope, и понадобилось ненулевое время
на исправление ситуации. В другом письме Вы (я все же надеюсь, что это
были Вы) пишете, что разработчики в своей деятельности должны
использовать самые модные наработки.

Отсюда с необходимостью следует, что, если мы говорим о том, что,
с одной стороны, HEAD ведется на последнем (в данный момент, 2.3)
питоне, а, с другой стороны, поддержку предыдущих версий _вашего_
продукта необходимо осуществлять в старом окружении, то мы с
необходимостью приходим к двум питонам и двум версиям каждого из модулей
на машине, по крайней мере, человека, который одновременно осуществляет
и разработку, и поддержку. Возможна, конечно, установка второй версии
питона куда-нибудь в chroot/vmware и т.п. но это требует по сути,
полноценного виртуального сервера.

> 4. Отказ от прекомпиляции является большой ошибкой, т.к. 
> прекомиплияция являетс существенным преимуществом языка питон.
С этим никто не спорит.

> По поводу py, pyc, pyo - я сейчас работаю над тем, что бы начится 
> безболезненно разбивать модули на три составляющих:
> 
> module-src, module, module-opt - каждый из которых содержит только
> один тип прекомпиленных модулей. Никаких проблем здесь не возникает 
> (так ставится один мой проект), но пока что это не автоматизировано, 
> чем собственно я и занимаюсь. На самом деле, я не вижу проблем в том, 
> что бы при установке модулей, в норме, не ставить исходников этих 
> модулей, что существенно экономит место и решает еще ряд проблем.
Замечательно. То, как это делает, н-р, emacs, можно взять за основу?
И, кстати, я испугался заранее фразы "решает еще ряд проблем". Что там
еще не так?

> Я это к тому, что бы было известно в какую сторону думаю, скажем, я.
Ok, буду иметь ввиду.

----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/20040117/b8d00d76/attachment-0001.bin>