[devel] Python Policy (was: Re: [SCM] packages/newt: heads/sisyphus)

[devel] Python Policy (was: Re: [SCM] packages/newt: heads/sisyphus)

[Evgeny Sinelnikov]

Здравствуйте,

28 сентября 2009 г. 23:04 пользователь Dmitry V. Levin
<ldv@altlinux.org> написал:
> On Mon, Sep 28, 2009 at 09:35:27PM +0300, Slava Dubrovskiy wrote:
> [...]
>> Ну тест репокопа ругается
>> http://sisyphus.ru/ru/srpm/Sisyphus/newt52/repocop : -
>> altlinux-python-obsolete-requires-python-version      Requires: python =
>> %__python_version is deprecated according to Python Policy
>> (http://www.altlinux.org/Python_Policy).
>>
>> И тут написано:
>>
>> 3.  Указание зависимостей
>>         3.1.    Пакет ДОЛЖЕН содержать явно указанную зависимость на
>> версию питона,
>>             использованного при его сборке. Такая зависимость вводится
>> указанием
>>             следующих операторов::
>>
>>                 Requires: python = %__python_version
>>
>>                 BuildPreReq: python-devel = %__python_version
>>
>>
>> А что-то не так понял?
>
> Мне кажется, что вы цитируете сборник атавизмов.

Как бы не смешно это было, но это правда...

> Попробуйте объяснить мне, зачем "Пакет ДОЛЖЕН содержать явно указанную
> зависимость на версию питона, использованного при его сборке"?

Даже не буду пробовать :)
Но это всё равно нужно проверить...

Действительно в старом python policy слишком много старых, не актуальных идей...

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

1. Есть ли возражения относительно подхода, когда в все пакеты с
питоновскими модулями будут именоваться pythonX.Y-module-%{name}? Я
предлагаю отказаться от "чистых" имён в пользу удобства именования и
однозначности при переездах на новые питоны.

2. Кто будет осуществлять поддержку python policy на уровне rpm?
Python Team? Если да, то прошу помочь реализовать средство подстановки
точной версии питона в shabang для скриптов. Сейчас я не совсем
понимаю куда это лучше встроить и как это должно работать. Для меня
это одно из основных препятствий для тестирования двух питонов.


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Python Policy (was: Re: [SCM] packages/newt: heads/sisyphus)

[REAL]

Evgeny Sinelnikov пишет:
> 1. Есть ли возражения относительно подхода, когда в все пакеты с
> питоновскими модулями будут именоваться pythonX.Y-module-%{name}? Я
> предлагаю отказаться от "чистых" имён в пользу удобства именования и
> однозначности при переездах на новые питоны.

Лично у меня возражений нет, ибо никогда такими именами не 
пользовался. Чем это лучше pythonX.Y(name)?

А вот насчёт имён python-module-%name в сборочных зависимостях - в 
случаях двух питонов что будет выбираться при сборке? Если будет две 
версии в сизифе, какая будет выбираться по умолчанию? Вариант 
переделывать ВСЕ спеки - очень нежелательный: пакетов очень много.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Python Policy (was: Re: [SCM] packages/newt: heads/sisyphus)

[Alexey Morozov]

Здравствуйте.

В сообщении от Среда 30 сентября 2009 01:28:49 автор Evgeny Sinelnikov 
написал:
> 1. Есть ли возражения относительно подхода, когда в все пакеты с
> питоновскими модулями будут именоваться pythonX.Y-module-%{name}? Я
> предлагаю отказаться от "чистых" имён в пользу удобства именования и
> однозначности при переездах на новые питоны.
Если интересно, заметная часть питон-модулей (включая .pyc/.pyo!) преспокойно 
переезжает из pythonX.Y в pythonX.<Y+1> . Исключения составляют те, кто 
завязан на libpython.so и другие ELF-библиотеки. Поэтому, как мне кажется, 
было бы разумнее, если бы бОльшая часть питон-модулей лежала где-нибудь в 
/usr/share/pythonX. Ну и остаётся некоторый риск того, что в каком-то из 
минорных апдейтов (слегка) сломают совместимость по байткоду.

Альтернативный подход применён в Debian Python Policy. У них предкомпиляция 
байткода осуществлялась, если я правильно помню, на машине конечного 
пользователя (на этапе dpkg-configure), в каталогах, специфичных для данной 
версии питона.

Посмотрите, кстати, может, и велосипед не надо изобретать :)

> 2. Кто будет осуществлять поддержку python policy на уровне rpm?
> Python Team? Если да, то прошу помочь реализовать средство подстановки
> точной версии питона в shabang для скриптов. Сейчас я не совсем
> понимаю куда это лучше встроить и как это должно работать. Для меня
> это одно из основных препятствий для тестирования двух питонов.
Вообще говоря, это осуществляется стандартными питоновскими distutils & Co.
Достаточно просто запускать не /usr/bin/python, а /usr/bin/pythonX.Y.

Собственно говоря, и зависимость на точную версию python пробивалась именно 
поэтому - во всех скриптах, которые зависели от установленных в 
/usr/lib/python/X.Y модулей, в хэшбэнге был именно pythonX.Y. 

Re: [devel] Python Policy

[REAL]

Alexey Morozov пишет:
> Если интересно, заметная часть питон-модулей (включая .pyc/.pyo!) преспокойно 
> переезжает из pythonX.Y в pythonX.<Y+1> . Исключения составляют те, кто 
> завязан на libpython.so и другие ELF-библиотеки. Поэтому, как мне кажется, 
> было бы разумнее, если бы бОльшая часть питон-модулей лежала где-нибудь в 
> /usr/share/pythonX. Ну и остаётся некоторый риск того, что в каком-то из 
> минорных апдейтов (слегка) сломают совместимость по байткоду.

Тут есть одна большая грабля: некоторые .py файлы различаются в разных 
версиях (где-то прописаны пути до каталога с модулем, где-то разные 
названия, в частности в python 2.6 недопустимо использовать в качестве 
имён as и with).

>> 2. Кто будет осуществлять поддержку python policy на уровне rpm?
>> Python Team? Если да, то прошу помочь реализовать средство подстановки
>> точной версии питона в shabang для скриптов. Сейчас я не совсем
>> понимаю куда это лучше встроить и как это должно работать. Для меня
>> это одно из основных препятствий для тестирования двух питонов.
> Вообще говоря, это осуществляется стандартными питоновскими distutils & Co.
> Достаточно просто запускать не /usr/bin/python, а /usr/bin/pythonX.Y.

А как будут исправляться шебанги в %_bindir и %_docdir? Особенно если 
не используется distutils.


-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Python Policy (was: Re: [SCM] packages/newt: heads/sisyphus)

[Andrey Rahmatullin]

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

On Wed, Sep 30, 2009 at 10:25:04AM +0700, Alexey Morozov wrote:
> Альтернативный подход применён в Debian Python Policy.
Туда посмотреть предлагали раза два, толку-то.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

В [husky-]current API и ABI могут меняться по 2-3 раза в день... и это
нормально!..
		-- ns in community@

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

Re: [devel] Python Policy

[Alexey Morozov]

В сообщении от Среда 30 сентября 2009 10:50:51 автор REAL написал:
> Тут есть одна большая грабля: некоторые .py файлы различаются в разных
> версиях (где-то прописаны пути до каталога с модулем, где-то разные
> названия, в частности в python 2.6 недопустимо использовать в качестве
> имён as и with).
Ну, да, вероятно. Вопрос только в том, какова вероятность встретить подобный 
модуль. Мне кажется, невелика. Я могу ошибаться.

> > Вообще говоря, это осуществляется стандартными питоновскими distutils &
> > Co. Достаточно просто запускать не /usr/bin/python, а /usr/bin/pythonX.Y.
> 
> А как будут исправляться шебанги в %_bindir и %_docdir?
Вот в %_bindir они и исправляются стандартными distutils'ами. _%docdir стоит 
особняком, и там, видимо, надо руками. Вообще, класть что-то исполняемое в 
%_docdir, по-моему, моветон.

> Особенно если не используется distutils.
Ну, смотрите документацию на то, что используется вместо distutils. Можно, 
конечно, и sed-скрипт написать и в конце сборки всех "принуждать к миру".

Re: [devel] Python Policy (was: Re: [SCM] packages/newt: heads/sisyphus)

[Alexey Morozov]

В сообщении от Среда 30 сентября 2009 10:56:00 автор Andrey Rahmatullin 
написал:
> On Wed, Sep 30, 2009 at 10:25:04AM +0700, Alexey Morozov wrote:
> > Альтернативный подход применён в Debian Python Policy.
> Туда посмотреть предлагали раза два, толку-то.
Ну, там тоже не всё здорово. По крайней мере, года два назад, я, используя 
только apt-get, умудрялся сломать работоспособность питоновского хозяйства на 
своём дебиановском десктопе. Впрочем, я его (Debian) традиционно не люблю, он 
отвечает мне взаимностью и гадит при каждом удобном случае, так что, я - не 
показатель :)

Re: [devel] Python Policy

[Andrey Rahmatullin]

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

On Wed, Sep 30, 2009 at 01:28:09PM +0800, REAL wrote:
> > Ну, да, вероятно. Вопрос только в том, какова вероятность встретить подобный 
> > модуль. Мне кажется, невелика. Я могу ошибаться.
> Вероятность = 1, потому что лично знаю такие модули :)
Такие модули фиксятся под последнюю версию питона. Почему бы модулю
работать под последнюю версию и не работать под предпоследнюю (не считая
ситуации, когда он специально написан под новые фичи) я не знаю. Ситуация,
когда модуль явно не поддерживает старую версию, решается несборкой модуля
под старую версию, как это, насколько я вижу, сделано в D**ian.

> > Вот в %_bindir они и исправляются стандартными distutils'ами. _%docdir стоит 
> > особняком, и там, видимо, надо руками. Вообще, класть что-то исполняемое в 
> > %_docdir, по-моему, моветон.
> Оно может не быть исполняемым, но стать таковым по желанию 
> пользователя (одно дело - скопировать себе и сделать chmod +x, совсем 
> другое - ещё и внутри править что-то неочевидное).
Ну будет работать под дефолтным питоном, ничего страшного.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

<thresh> с другой стороны, мышка microsoft будет хорошо смотреться рядом с
         маком на котором запущен linux

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

Re: [devel] Python Policy

[REAL]

Alexey Morozov пишет:
> Ну, да, вероятно. Вопрос только в том, какова вероятность встретить подобный 
> модуль. Мне кажется, невелика. Я могу ошибаться.

Вероятность = 1, потому что лично знаю такие модули :)

> Вот в %_bindir они и исправляются стандартными distutils'ами. _%docdir стоит 
> особняком, и там, видимо, надо руками. Вообще, класть что-то исполняемое в 
> %_docdir, по-моему, моветон.

Оно может не быть исполняемым, но стать таковым по желанию 
пользователя (одно дело - скопировать себе и сделать chmod +x, совсем 
другое - ещё и внутри править что-то неочевидное).

>> Особенно если не используется distutils.
> Ну, смотрите документацию на то, что используется вместо distutils. Можно, 
> конечно, и sed-скрипт написать и в конце сборки всех "принуждать к миру".

Думаю, нужно не мейнтейнерам куда-то смотреть (ибо зачем тогда вообще 
это всё, раз другим будет лишний геморрой), а сделать автоматику при 
сборке. О чём речь изначально и велась.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Python Policy

[Alexey Morozov]

В сообщении от Среда 30 сентября 2009 12:28:09 автор REAL написал:
> Alexey Morozov пишет:
> > Ну, да, вероятно. Вопрос только в том, какова вероятность встретить
> > подобный модуль. Мне кажется, невелика. Я могу ошибаться.
> Вероятность = 1, потому что лично знаю такие модули :)
Да, вероятность - плохое слово. Переформулирую: сколько в штуках таких 
модулей?

> Думаю, нужно не мейнтейнерам куда-то смотреть (ибо зачем тогда вообще
> это всё, раз другим будет лишний геморрой),
Потому что смотреть в документацию по используемой в данном модуле сборочной 
системе всё равно придётся. Хотя бы для того, чтобы модули легли в 
соответствии с желаемым расположением. Вероятно, часть общеупотребительных 
вещей можно унести и в макросы, отчего нет :)

> а сделать автоматику при сборке. О чём речь изначально и велась.
Пожелание - не переусердствуйте с автоматикой.

Re: [devel] Python Policy

[REAL]

Alexey Morozov пишет:
>>> Ну, да, вероятно. Вопрос только в том, какова вероятность встретить
>>> подобный модуль. Мне кажется, невелика. Я могу ошибаться.
>> Вероятность = 1, потому что лично знаю такие модули :)
> Да, вероятность - плохое слово. Переформулирую: сколько в штуках таких 
> модулей?

Не считал. Но сам несколько таких модулей правил. Включая и свои 
собственные, но не только. Из совсем недавнего - python2.x(Gnuplot).

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] Python Policy: autofixing shebang in python scripts

[Dmitry V. Levin]

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

On Tue, Sep 29, 2009 at 10:28:49PM +0400, Evgeny Sinelnikov wrote:
> 28 сентября 2009 г. 23:04 пользователь Dmitry V. Levin написал:
> > On Mon, Sep 28, 2009 at 09:35:27PM +0300, Slava Dubrovskiy wrote:
[...]
> 2. Кто будет осуществлять поддержку python policy на уровне rpm?
> Python Team? Если да, то прошу помочь реализовать средство подстановки
> точной версии питона в shabang для скриптов. Сейчас я не совсем
> понимаю куда это лучше встроить и как это должно работать. Для меня
> это одно из основных препятствий для тестирования двух питонов.

В качестве быстрого хака, чтобы вы могли продолжить работу, могу
предложить внедриться в /usr/lib/rpm/shebang.req; он, конечно,
предназначен для вычисления зависимостей, и не должен менять файлы,
но в качестве быстрого хака подойдёт.


-- 
ldv

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