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

[Andrey Orlov <cray@neural.ru>]

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 если я правильно понимаю.

> > И такая привязка - хорошо, потому что альтернативы нет.
> Привязка для _скриптов_? Можно сузить область обсуждения: для 
скриптов,
> которыми питоньи .tex-доки конвертируются в различные другие 
форматы?
> Нет, я с Вами не согласен. Если бы это было так, то на питоне вообще
> ничего нельзя было бы писать. По счастью, на таком уровне переезд с
> одной версии на другую осуществляется безболезненно, так что,
> зависимости на python2.2 или python2.3 здесь быть не должно.

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

> Итого, сухой остаток:
> 
> Долой /usr/lib/rpm/brp-bytecompile_python!
> Даешь /usr/lib/rpm/python.{req,prov}!

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

Если вы считаете что _ваш_ пакет не должен содержать *pyc & *pyo - вы
можете не _включать_ их в секцию files _вашего_ spec'а. А все 
глобальные изменения порядка комплиции стоит согласовывать со всеми. 
Пока что _лично_я_ против таких изменений, и  я хотя я согласен что 
ситуацию с pyc & pyo надо менять - я против изъятия прекомпиляции как 
таковой, так как наличие байткомпиляции является существенным 
преимуществом питона перед, скажем, перлом. 

> Давайте жить дружно!

Давайте, только прислушивайтесь к чужому мнению? На сегодняшний день 
оно такое:

 1. Перенос байт-кода из одной версии в другую не допустим;

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

3. Сама проблема двух питонов является надуманной, так как никакой 
необходимости держать два питона на одной машине я не знаю;

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

По поводу py, pyc, pyo - я сейчас работаю над тем, что бы начится 
безболезненно разбивать модули на три составляющих:

module-src, module, module-opt - каждый из которых содержит только
один тип прекомпиленных модулей. Никаких проблем здесь не возникает 
(так ставится один мой проект), но пока что это не автоматизировано, 
чем собственно я и занимаюсь. На самом деле, я не вижу проблем в том, 
что бы при установке модулей, в норме, не ставить исходников этих 
модулей, что существенно экономит место и решает еще ряд проблем.

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

-- 
Спасибо за проявленное понимание -
-- Андрей Орлов