[devel] Python Modules Policy:

[Алексей Любимов]

>Не вопрос. Мы с Андреем уже договорились (в джаббере) до того, что
>
>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 того питона, для которого производилась сборка.
>
Это понятно.

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

>7. Программы, имеющие такую привязку (н-р, идущие вместе с конкретной
>   версией питона) иcпользуют #!/usr/bin/env python<version> ...
>   и могут таскать за собой байткод.
>
В скриптах? и вы согласны переписывать все скрипты в модуле при переходе 
версий???

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

У меня вот зреет какое то общее средство под кодовым названием stripper.
В пакеты кладутся схемы файлов в виде регэкспов.
Также пишуться глобальные регэкспы типа __nodoc__  = /usr/share/doc/.*
__noman__ =  /usr/share/man/.* /.*

__nopy_source__ = *.py

__nopy_pyc__ = *.pyc


В любой момент, включая установку пакета, можно вызвать stripper 
пакет(ы) и он обрежет по правилам файлы и перенесет их в архив или 
вернет обратно.
Также можно поставить правила по умолчанию и они будут срабатывать при 
установке пакетов сами.

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