[devel] Python Modules Policy:

[Alexey Morozov]

On Tue, Feb 10, 2004 at 06:51:18PM +0300, Алексей Любимов wrote:
> 
> >Не вопрос. Мы с Андреем уже договорились (в джаббере) до того, что
> >
> >1. Он проставляет Obsoletes: pythonN в python{N+1} или делает
> >  аналогичные изменения, о точном решении будет сообщено
> >  дополнительно ориентировочно в конце недели.
> >2. _Одновременная_ сборка пакетов под разные версии питона является
> >  на данный момент ненужной ввиду своей трудоемкости.
> реально это означает, что поддержка python22 отменяется.
> Или, проще говоря, на зоп* в сизифе и все, что посложнее "hello world" 
> можно забить.
Нет. Их можно будет собирать "неодновременно", т.е. в два прохода.
Может быть, даже автоматом.


> >3. Андрей думает над целесообразностью сборки пакетов вида
> >  python<N>-ModuleName из исходника вида python-ModuleName
> Если будет строго выполнен пункт 2, то это имхо лишнее...
> Уж если у кого дойдут руки, то можно делать пакеты python22-ModuleName
> то есть схема пакет и compat-пакет, а не ПакетВерсия1 и ПакетВерсия2
См. выше про автомат.

> >5. В полиси для питоньих модулей вносится обязательный
> >  Requires: python = %<pversion>, где %<pversion> совпадает с
> >  %__python_version того питона, для которого производилась сборка.
> Это понятно.
ldv@ уже предложил решение, которое, вроде бы, не хуже по последствиям,
но автоматизируется. Прокомментируйте его, пожалуйста.


> >Предлагается подумать над следующими двумя полиси:
> >6. Программы на python, не зависящие от конкретной версии питона
> >  (epydoc, python-doc-tools), собираются _без_ байткода и,
> >  соответственно, без привязки к точной версии питона, используется
> >  #!/usr/bin/env python ...
> А где же они лежать будут? по логике все равно в python?.?/site-packages/
Нет. Питоньи скрипты (н-р, python-doc-tools) лежат не там.
epydoc тоже лежит не там, вроде бы. Если нужно подумать над
"версионно-независимом" каталоге для питона, его можно организовать,
насколько я понимаю.


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


> >7. Программы, имеющие такую привязку (н-р, идущие вместе с конкретной
> >  версией питона) иcпользуют #!/usr/bin/env python<version> ...
> >  и могут таскать за собой байткод.
> В скриптах? и вы согласны переписывать все скрипты в модуле при переходе 
> версий???
Если эти _скрипты_ завязаны на данную версию питона: да, согласен.
Но, мой опыт (сборки twisted) показывает, что достаточно внятно разделить:
вот этот пакет - модул{ь,и}, он[и] привязан[ы] к версии питона, а вот
это - скрипты [из /usr/bin], которые одинаково хорошо работают как с
твистедом, собранным под 2.2, так и с твистедом, собранным под 2.3

> >8. Некоторое время назад Андрей предлагал в "боевых" пакетах таскать
> >  только байткод, а .py заворачивать в отдельные пакеты "для
> >  интересующихся" (по моему разумению, по схеме, напоминающей то, что
> >  делает Алекс Отт для емакса, хотя _это мои предположения_)
> И наплодить еще дубликатов-пакетов пачку.
У Андрея были практические соображения, почему в боевую версию НЕ надо
пихать сорцы. С другой стороны, мой небольшой практический опыт
показывает, что сорцы _иногда_ нужны.

> У меня вот зреет какое то общее средство под кодовым названием stripper.
...
> Также можно поставить правила по умолчанию и они будут срабатывать при 
> установке пакетов сами.
Это никак не упихивается в рамки distutils?

> 
> Незрело, конечно, но по моему, вполне может получится...
Показывайте.

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