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

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

[Alexey Morozov]

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

Проблема:

Имеется некоторый пакет (python-doc-tools), который, по сути своей,
набор макросов, скриптов итп. Среди макросов встречаются .py.

Установка этого пакета предельно проста: тарболл разворачивается, по
сути, в некоторое место в [%buildroot]/usr/share.

Соответственно, никаких вызовов питона или чего-нить подобного нету.
Более того, хотелось бы _НЕ_ компилировать питон в байткод, потому что
там, в общем, ничего серьезного или постоянно загружаемого нет. Временем
загрузки тех скриптов можно пренебречь с хорошей долей уверенности.

Однако /usr/lib/rpm/brp-alt БЕЗ ВАРИАНТОВ запускает
/usr/lib/rpm/brp-bytecompile-python, что приводит к двум нежелательным
последствиям:

1. Появляются .pyo. Как меня уверяли (кто-то из команды, занимающийся
сборкой питона & Co), байткод от разных версий питона непереносим, хуже
того, совместимости даже взад никто не обещал. Как следствие, происходит
неявная привязка к версии питона, которая стояла в момент загрузки. Это
ПЛОХО.

2. Т.к. rpm-build НЕ ТРЕБУЕТ python'а, хотя и пользуется им вне зависимости
от желаний сборщика, сборка в хэшере обламывается, хотя, в общем, пакет
совсем не должен отвечать ни за что, что лежит за пределами его .spec и
прочих его сорцов.

С этим НАДО ЧТО-ТО ДЕЛАТЬ :-)).


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

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

[Dmitry V. Levin]

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

On Tue, Jan 13, 2004 at 07:02:37PM +0600, Alexey Morozov wrote:
> Проблема:
> 
> Имеется некоторый пакет (python-doc-tools), который, по сути своей,
> набор макросов, скриптов итп. Среди макросов встречаются .py.
> 
> Установка этого пакета предельно проста: тарболл разворачивается, по
> сути, в некоторое место в [%buildroot]/usr/share.
> 
> Соответственно, никаких вызовов питона или чего-нить подобного нету.
> Более того, хотелось бы _НЕ_ компилировать питон в байткод, потому что
> там, в общем, ничего серьезного или постоянно загружаемого нет. Временем
> загрузки тех скриптов можно пренебречь с хорошей долей уверенности.
> 
> Однако /usr/lib/rpm/brp-alt БЕЗ ВАРИАНТОВ запускает
> /usr/lib/rpm/brp-bytecompile-python, что приводит к двум нежелательным
> последствиям:
> 
> 1. Появляются .pyo. Как меня уверяли (кто-то из команды, занимающийся
> сборкой питона & Co), байткод от разных версий питона непереносим, хуже
> того, совместимости даже взад никто не обещал. Как следствие, происходит
> неявная привязка к версии питона, которая стояла в момент загрузки. Это
> ПЛОХО.
> 
> 2. Т.к. rpm-build НЕ ТРЕБУЕТ python'а, хотя и пользуется им вне зависимости
> от желаний сборщика, сборка в хэшере обламывается, хотя, в общем, пакет
> совсем не должен отвечать ни за что, что лежит за пределами его .spec и
> прочих его сорцов.
> 
> С этим НАДО ЧТО-ТО ДЕЛАТЬ :-)).

Есть набор workaround'ов:

1. %undefine __python:
выключает всю логику поддержки python, в т.ч. и
/usr/lib/rpm/brp-bytecompile-python

2. unset RPM_PYTHON в конце %install выключает
/usr/lib/rpm/brp-bytecompile-python

3. "buildreq -bi" умеет обнаруживать сборочные зависимости на python.


-- 
ldv

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

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

[Alexey Morozov]

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

On Tue, Jan 13, 2004 at 04:16:18PM +0300, Dmitry V. Levin wrote:
> Есть набор workaround'ов:
> 
> 1. %undefine __python:
> выключает всю логику поддержки python, в т.ч. и
> /usr/lib/rpm/brp-bytecompile-python
Ну, это оверкилл

> 2. unset RPM_PYTHON в конце %install выключает
> /usr/lib/rpm/brp-bytecompile-python
Done.

> 3. "buildreq -bi" умеет обнаруживать сборочные зависимости на python.
?
alex@pyro ~/RPM/SPECS $ buildreq -bi python-doc-tools.spec 
buildreq: invalid option -- b
buildreq - generates and adds/updates BuildRequires tag in specfiles.
...

А просто buildreq python-doc-tools.spec эту зависимость не ловит.

Ну, в вообще, это не то, на самом деле, чего хотелось бы добиться.

#2 более разумен, как мне кажется. В связи с этим возникает вопрос,
адресованный, скорее, Python Development Team: а не стоит ли вообще удалить
нафиг такую "умолчательную" байткомпиляцию, заменив ее более на
стандартизованные методы сборки питоньих модулей?

Я попробовал, там, вроде, как и в случае с perl'ом, всё замечательно
macro'фицируется (старик Державин корчится от ужаса). Вечером поднимется
Мишин хэшер, я пересоберу всё там, и смогу отдавать со спокойной
совестью на суд общественности. Да, для самых нетерпеливых положил
src.rpm'ы и спеки на http://woland.iae.nsk.su/~alex/python/. Там многое
непричесано, собственно, макросов как таковых и нет почти, но если
какие-то идеи будут востребованы, при проталкивании в upstream их и до
ума можно будет довести.

Пока решил, собирать пакеты в python<version>-<modulename> прежде всего
для удобства этого самого тестирования. В принципе, всю машинерию по 
"два пакета из одного srpm'а" можно убрать, но, мне кажется, различие по
версиям стоит сохранить, хотя бы для тех, кому по каким-то причинам
понадобилось _локально_ держать обе версии питона (н-р, на время
переезда на следующую версию)

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

Кстати, есть ли для питона rpm-скрипты, аналогичные perl.req или
perl.prov? Задача-то более решаема, на первый взгляд, чем для перла...

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

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

[Dmitry V. Levin]

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

On Wed, Jan 14, 2004 at 09:04:40PM +0600, Alexey Morozov wrote:
> On Tue, Jan 13, 2004 at 04:16:18PM +0300, Dmitry V. Levin wrote:
> > 3. "buildreq -bi" умеет обнаруживать сборочные зависимости на python.
> ?
> alex@pyro ~/RPM/SPECS $ buildreq -bi python-doc-tools.spec 
> buildreq: invalid option -- b
> buildreq - generates and adds/updates BuildRequires tag in specfiles.
> ...

rpm-utils >= 0.7.3-alt1

> А просто buildreq python-doc-tools.spec эту зависимость не ловит.

Эта зависимость проявляется только на стадии %install, а buildreq сейчас
ловит только до %build включительно.

Есть интересное предложение на эту тему, см.
http://bugzilla.altlinux.ru/show_bug.cgi?id=1099

> #2 более разумен, как мне кажется. В связи с этим возникает вопрос,
> адресованный, скорее, Python Development Team: а не стоит ли вообще удалить
> нафиг такую "умолчательную" байткомпиляцию, заменив ее более на
> стандартизованные методы сборки питоньих модулей?

А зачем?  Чего хотелось бы добиться?

> Кстати, есть ли для питона rpm-скрипты, аналогичные perl.req или
> perl.prov? Задача-то более решаема, на первый взгляд, чем для перла...

В PLD, кажется, есть.


-- 
ldv

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

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

[Alexey Morozov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jan 14, 2004 at 06:16:37PM +0300, Dmitry V. Levin wrote:
> > alex@pyro ~/RPM/SPECS $ buildreq -bi python-doc-tools.spec 
> > buildreq: invalid option -- b
> > buildreq - generates and adds/updates BuildRequires tag in specfiles.
> rpm-utils >= 0.7.3-alt1
Ясно.

> Есть интересное предложение на эту тему, см.
> http://bugzilla.altlinux.ru/show_bug.cgi?id=1099
Ну, в общем, интересное предложение. Только вот насколько просто реализуемое? 
То есть, я не против, но и говорить, что мне это настолько нужно, что я 
возьмусь это имплементировать, тоже не буду :-)).

> > #2 более разумен, как мне кажется. В связи с этим возникает вопрос,
> > адресованный, скорее, Python Development Team: а не стоит ли вообще
> > удалить нафиг такую "умолчательную" байткомпиляцию, заменив ее более на
> > стандартизованные методы сборки питоньих модулей?
> А зачем?  Чего хотелось бы добиться?
Причина, по большому счету, одна. Если модуль собирается не той и не для той 
версии питона, которая вызывается через %__python, то такая операция, вообще 
говоря, некорректна. Плюс к тому, setup.py, грубо говоря, знает, что вот 
этот, этот и вот этот .py - не "модуль", а "скрипт", который, собственно, и 
байт-компилировать на диск не следует. На этапе "автоматической компиляции" 
такая информация уже отсутствует.

> > Кстати, есть ли для питона rpm-скрипты, аналогичные perl.req или
> > perl.prov? Задача-то более решаема, на первый взгляд, чем для перла...
> В PLD, кажется, есть.
Ну, пока не нашел. То есть, ссылки на python.req/python.prov в соответствующих 
скриптах видел, а самих файлов - нет.

P.S. Не в тему, но все же интересно: Дмитрий, что Вы решили насчет libtool? 
Какие шаги нужно предпринять, чтобы это Ваше решение ускорить?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAB1HQX5DZdJn19V0RAgiLAJ9CY3x7jC8487aVvEogIxmpk5FYDACeNj7I
3Q2WabWeZ+VCVcCQSTNhFYk=
=p6yf
-----END PGP SIGNATURE-----

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

[Michael Shigorin]

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

On Wed, Jan 14, 2004 at 09:04:40PM +0600, Alexey Morozov wrote:
> Кстати, есть ли для питона rpm-скрипты, аналогичные perl.req
> или perl.prov? Задача-то более решаема, на первый взгляд, чем
> для перла...

Кажется, Бормотов что-то такое делал.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

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

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

[Andrey Orlov]

On Tuesday 13 January 2004 16:02, Alexey Morozov wrote:
> Соответственно, никаких вызовов питона или чего-нить подобного нету.
> Более того, хотелось бы _НЕ_ компилировать питон в байткод, потому что

> 1. Появляются .pyo. Как меня уверяли (кто-то из команды, занимающийся
> сборкой питона & Co), байткод от разных версий питона непереносим, хуже
> того, совместимости даже взад никто не обещал. Как следствие, происходит

Алексей, извините ради бога, но не могли бы вы не перевирать то, что вам говорят?
Особенно автороство того, кто и что вам говорит? На этот вопрос
отвечали, в разное время, два человека - я & Максим, и ответ был совсем не такой.

Скажем, то что сказал недавно вам я - __код__ от разных версий не переносим в общем
случае, а не байт-код. Это не значит, что байт-код переносим, но это значит, что ссылки
на непереносимость именно байт-кода несостоятельны, так как код для разных версий
python все равно будет падать.

> неявная привязка к версии питона, которая стояла в момент загрузки. Это
> ПЛОХО.

И такая привязка - хорошо, потому что альтернативы нет.

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

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

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

[Alexey Morozov]

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

On Fri, Jan 16, 2004 at 10:12:43AM +0300, Andrey Orlov wrote:
> > 1. Появляются .pyo. Как меня уверяли (кто-то из команды, занимающийся
> > сборкой питона & Co), байткод от разных версий питона непереносим, хуже
> > того, совместимости даже взад никто не обещал. Как следствие, происходит
> Алексей, извините ради бога, но не могли бы вы не перевирать то, что вам
> говорят?
Стараюсь. Вы зря так горячитесь, Андрей. С другой стороны, я рад, что Вы
читаете мои письма :-)

> Особенно автороство того, кто и что вам говорит? На этот вопрос
> отвечали, в разное время, два человека - я & Максим, и ответ был совсем
> не такой.
Вопрос был другой :-)). И отвечали на него не Вы :-)

> Скажем, то что сказал недавно вам я - __код__ от разных версий не переносим в > общем случае, а не байт-код.
Нет, меня интересует именно _байт-код_.

И спрашивал я, переносим ли байт-код, между различными версиями питона,
и между различными платформами:

http://www.altlinux.ru/pipermail/community/2003-December/105800.html

И вот ответ _Максима_:

http://www.altlinux.ru/pipermail/community/2003-December/105808.html

Хотя, в общем, я уже прочел

http://www.python.org/doc/current/tut/node8.html#SECTION008120000000000000000

откуда, вроде бы, следут, что содержимое нашей нынешней

/usr/lib/python2.2

можно перевозить в

/usr/share/python2.2

Кто прав, Максим или доки на питон, я не знаю, но это, в общем, в
контексте вопроса, обсуждаемого в _этом_ треде, и не важно.

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

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

А вообще, кому она нужна эта посткомпиляция? При условии, конечно, что
мы для всех, кому эта компиляция (даже с оптимизацией! какие молодцы!)
действительно нужна, можем проводить ее на этапе %build или %install,
благо distutils - мощная и гибкая штука.

Итого, сухой остаток:

Долой /usr/lib/rpm/brp-bytecompile_python!
Даешь /usr/lib/rpm/python.{req,prov}!

и

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

?


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

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

[Klimchev Konstantin]

On Fri, 16 Jan 2004 16:50:05 +0600
Alexey Morozov <alex@idisys.iae.nsk.su> wrote:

> кому эта компиляция (даже с оптимизацией! какие молодцы!)
> действительно нужна, можем проводить ее на этапе %build или %install,
> благо distutils - мощная и гибкая штука.

К сожаление не все сделано через distutils

> 
> Итого, сухой остаток:
> 
> Долой /usr/lib/rpm/brp-bytecompile_python!

Наверное не долой, а умолчательно выключено, но можно при желание включить

> Даешь /usr/lib/rpm/python.{req,prov}!

Не помешало бы.

-- 
Best Regards, Konstantin Klimchev 
(mailto:koka@atvc.ru    jabber:koka@jabber.ru)
ATK-Internet ISP, Arkhangelsk, Russia

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

[Alexey Morozov]

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

On Fri, Jan 16, 2004 at 02:30:09PM +0300, Klimchev Konstantin wrote:
> > действительно нужна, можем проводить ее на этапе %build или %install,
> > благо distutils - мощная и гибкая штука.
> К сожаление не все сделано через distutils
Поставим вопрос так:

distutils - это, статистически, правило, или исключение?

Если правило - ориентироваться надо на него.

> > Итого, сухой остаток:
> > 
> > Долой /usr/lib/rpm/brp-bytecompile_python!
> Наверное не долой, а умолчательно выключено, но можно при желание включить
Ok.

> > Даешь /usr/lib/rpm/python.{req,prov}!
> Не помешало бы.
Только я пока не нашел,

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

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

[Klimchev Konstantin]

On Fri, 16 Jan 2004 17:46:44 +0600
Alexey Morozov <alex-altlinux@idisys.iae.nsk.su> wrote:

> distutils - это, статистически, правило, или исключение?

правило, но как у всякого правила есть исключения (MenuMaker, например).

> 
> Если правило - ориентироваться надо на него.

полностью согласен

-- 
Best Regards, Konstantin Klimchev 
(mailto:koka@atvc.ru    jabber:koka@jabber.ru)
ATK-Internet ISP, Arkhangelsk, Russia

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

[Andrey Orlov]

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 - каждый из которых содержит только
один тип прекомпиленных модулей. Никаких проблем здесь не возникает 
(так ставится один мой проект), но пока что это не автоматизировано, 
чем собственно я и занимаюсь. На самом деле, я не вижу проблем в том, 
что бы при установке модулей, в норме, не ставить исходников этих 
модулей, что существенно экономит место и решает еще ряд проблем.

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

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

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

[Alexey Morozov]

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

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, буду иметь ввиду.


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

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

[Andrey Orlov]

On Friday 16 January 2004 22:58, Alexey Morozov wrote:
> > Скомпиленный питоновский модуль нельзя разместить с другим путем. Так
>
> Но можно же задать при сборке собственно питона другое расположение
> библиотечных путей, правда?

Библиотечный путь тут не причем. Речь о пути к исходному файлу питона в момент
компиляции.

>> Андрей, я понимаю Вашу озабоченность проблемами сборки Zope. Но у меня
> сейчас немного другие проблемы, не затрагивающие впрямую Zope. И я НЕ
> претендую на универсальность моего решения.

Я Zope привожу только как пример. Просто этот пример подтвержден другими
людьми и мне есть на что сослатся. А так - проблемы могут возникнуть  практически
со всеми скриптами. 

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

Я уже предлагал 2 варианта: 

1. отменять байт-комплилицию для определенного каталога (надо только посотреть ка это лушче сделать)

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


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

У нас нет переносимости кода - мы пересобираем модули и пакеты при появлении 
нового питона, нового С, и т.п.

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

У нас нет перенесения байт кода. По вышеописанным причинам. В каждом пакете
стоит требование определенного питона. Кроме того альтернативы, python22 & 23 скомпиены
с разными путями, а модули для разных питонов ложаться в разные каталоги. И вообще,
как я уже сказал, python22 в норме использоватся не должен вообще. 

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

Интересно, почему это не так? У меня это вроде как так. И на описанную вами ситуацию
я ни разу не нарывался. Мбть что-то у вас подпраить надо?

> А во-вторых, мне, все же, больше
> нравится оперировать списком файлов, сформированных на этапе

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

А вы и оперируете этим списком. Просто фильтруете и раскладываете его по
трем пакетам. Кроме того, если этот список содержит прекомпиленные модули - 
то чего же вы от них отказываетесть? А если он их не содержит - то как же они
попадают в пакет, если вы используете этот список? Что-то  вы тут меня запутать
пытаетесь, похоже ;).

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

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

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

Я тогда так и не понял о чем речь. Т.е. какую проблему вы пытаетесь решить

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

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

Только вы зачем-то пытаетесь придумать какой-то невозможный гибрид из
двух разных версий питона в одном дистрибутиве, с пересборкой всех модулей
и скриптов под оба питона сразу. Я не понимаю зачем это нужно. Мало того, 
я не понимаю, если вам это нужно - то почему вы списали со счетов python21 и
python1.52? Я могу привести примеры кода и примеры пакетов, для которых
такое списание может оказатся преждевременным (некоторые
продукты для того же Zope). Но - мы же их портируем...

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

Я уже объяснил - для поддежки старых версий существует AltLinuxMaster22 и 
апдейты к нему.  Везде на хостинге у меня стоит ALM22, а в одном сильно коммерческом
месте - ALM20, и я _не_собираюсь_ его апдейтить до сизифа по неоднократно
описанным вами причинам. Там стоит софт, на портирование которого нет
денег. Но сизиф - для разработчиков. 

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

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

> > Замечательно. То, как это делает, н-р, emacs, можно взять за основу?

Напомните, что делает emacs?

> И, кстати, я испугался заранее фразы "решает еще ряд проблем". Что там
> еще не так?

В основном это так скажем, условно, "словари". Код очень большого объема, частично
автоматически генерированный. Если мы ставим py+pyc+pyo - получается некислый
объем на диске. Хотя из них, при соблюдении определенных предостарожностей, любые
два можно изъять. Сейчас в rPAS (это собствено пакет на котором я ставлю опыты)
спокойно работает при установке для таких продуктов только файлов *pyc, когда
цели отладки требуют  - всегда можно доставить соотв. пакет -src. В принципе,
удобно, но в rPAS и так 15 пакетов, а с таким делением получается 35, что немного
тяжело для поддержки. C Zope ситуация примерно та же. Вот сбсно над проблемами 
автоматизации я в свободное время размышляю. Кстати, я не прочь поразмышлять 
вместе, тем более, что насколько я понял, вы хороший специалист по макросам rpm и т.п.

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

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

[Alexey Morozov]

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

Я сегодня отправлю ответ "по существу" из дома, за трое суток он, слава
Богу, успел отлежаться и, надеюсь, стать более конструктивным :-)),
а пока скажите пожалуйста, есть ли где-нибудь место где можно было в
real-time потрепаться "за питон" (предпочтительно по-русски, но можно и
по-английски, не проблема). Просто я вижу, что есть у меня вопросы,
которые иначе как моей неосведомленностью в вопросах питон-девелопмента
не объяснишь, хотелось бы послушать умных людей.


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

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

[Andrey Orlov]

В сообщении от Понедельник 19 Январь 2004 18:13 Alexey Morozov написал:
> Я сегодня отправлю ответ "по существу" из дома, за трое суток он, слава
> Богу, успел отлежаться и, надеюсь, стать более конструктивным :-)),
> а пока скажите пожалуйста, есть ли где-нибудь место где можно было в
> real-time потрепаться "за питон" (предпочтительно по-русски, но можно и
> по-английски, не проблема). Просто я вижу, что есть у меня вопросы,
> которые иначе как моей неосведомленностью в вопросах питон-девелопмента
> не объяснишь, хотелось бы послушать умных людей.

Понятия не имею. Со мной можно потрепатся на jid: cray@altlinux.org или
+7 926 222 99 63. Я не то чбы особо умный, просто прикидываюсь.

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

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

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

[Dmitry V. Levin]

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

On Sat, Jan 17, 2004 at 01:58:39AM +0600, Alexey Morozov wrote:
> On Fri, Jan 16, 2004 at 06:10:40PM +0300, Andrey Orlov wrote:
> > On Friday 2004  January 16 13:50, Alexey Morozov wrote:
[...]
> > > Кто прав, Максим или доки на питон, я не знаю, но это, в общем, в
> > > контексте вопроса, обсуждаемого в _этом_ треде, и не важно.
> > Скомпиленный питоновский модуль нельзя разместить с другим путем. Так
> Но можно же задать при сборке собственно питона другое расположение
> библиотечных путей, правда?
> 
> > как после этого он начинает немножко неправильно работать, (кажется, 
> > в частности, выдавать неверную диагностику). Установлено это было еще 
> > до моего прихода в команду, и кажется именно этим обусловлена 
> > __двойная__ байт-компиляция всего питоновского кода. Подробнее об 
> > этом может рассказать LDV если я правильно понимаю.
> Ok, спросим LDV.

Ok, историческая справка.

В те времена, когда я занимался первичной упаковкой python и модулей к
нему (~2000 год), python при обработке .pyc/.pyo проверял, находятся ли
они в том самом месте файловой системы, для которого они были
байт-скомпилированы.  По причинам, которые я сейчас уже не помню, все
собиравшиеся тогда модули почему-то байт-компилировались во время "make
install" таким образом, что $RPM_BUILD_ROOT попадал в информацию об
установочном пути, в результате чего после установки пакета от этого
байт-кода уже не было никакой пользы (python его игнорировал).  Отсюда и
появилась принудительная "правильная" байт-компиляция по окончании
секции %install.


-- 
ldv

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

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

[Andrey Orlov]

On Saturday 17 January 2004 02:20, Dmitry V. Levin wrote:
> install" таким образом, что $RPM_BUILD_ROOT попадал в информацию об
> установочном пути, в результате чего после установки пакета от этого
> байт-кода уже не было никакой пользы (python его игнорировал).  Отсюда и

Я сейчас проверил, по крмре в коде python2.3/import.c, такой проверки нет,
обходятся mtime. И тестирование продемонстрировало что такой проверки нет,
ну или пкрмре я ее не нашел покрмре для *pyc файлов. 

В тоже время, путь и имя исходного файла сохраняются в *pyc и существует
воспроизводимая ситуация, в которой этот путь будет отображен в traceback при
исключении (отсутствие исходного модуля при наличии скомпилированного),
так что хотя проблема теперь стоит, видимо, не так остро, она осталась.

(все проверки делались на python-2.3.3-alt4.2, это моя домашняя сборка, прототип alt5)

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