[devel] Re: A: Полиси ( я свел все воедино ) + FAQ

[Andrey Orlov <cray@neural.ru>]

On Monday 23 February 2004 00:40, you wrote:
> Hello Andrey,
>
> On Sun, Feb 22, 2004 at 10:32:27PM +0300, Andrey Orlov wrote:
> >         2.  В день выхода новой минорной версии python (X.Y), делается
> > форк: новая версия собирается под именем python, тогда как старая - под
> > именем pythonXY-1;
>
> Что за "-1"? Почему не просто pythonXY версии X.Y.Z, как у людей?

Если (X,Y) == (2,4), то  pythonXY-1 == python23, подстрока Y-1 обозначала
"предыдущую версию".

> >             Замечание 1: Более строго было бы использовать имя
> > pythonX.Y-1, но тут сложилась некая традиция, не уверен, что хорошая;
>
> Это какой-то ментальный блок, существующий со времён kernelXY,
> а то и раньше.

Да, наверно. Мне так тоже неудобно.

> >         4.  Новая схема сборки модулей гарантирует (зависмостямb)
> >             невозмиожность установки модулей от старых версий python с
> > его новыми версиями
>
> По-моему, слишком жёсткое ограничение.

Нет, не слишком, если мы хотим более-менее надежной работы.

> Нужно решить лишь такую задачу: если есть зависимость между модулями,
> эта зависимость должна учитывать версию python ABI. Как этого можно
> достичь, я писал.

Увы, но синтаксис языка тоже менятся, не оставаясь до конца совместимым
ни вперед, ни назад. Zope для версии 2.2 разражается кучей предупреждений
и ввалится, при запуске с 2.3, причем исключительно из-за проблем синтаксиса.

> >             (по крайней мере на уровне минорных версий,
> >             нужно ли затрагивать сабминоры - вопрос открытый, выйдет
> >             python2.3.4 - посмотрим);
>
> Я думаю, можно полагаться на неявное обязательство разработчиков
> Python не ломать ABI между микро-релизами.

Я тоже думаю, только как я уже написал - дело не в ABI, а в синтаксисе.

> >         Я медленно, но верно, пилю питон на части.
>
> В этом процессе главное -- чувство меры ;)

Потому и медленно. Нет, я не пытаюсь распилить его на "все" модули, по одному файлу
на пакет. Только на крупные группы: python-modules-xml, python-modules-http, примерно так.

> Я правильно понял, что python это "панама", которая тянет python-base
> и python-modules?

Да, python-weak - вторая панама, которая провайдит python.

> >             python-obsoletes -- пакет, содержащий фрагменты python,
> > которые объявлены устаревшими (например, rotor.py) или несекъюрными (он
> > же, в более ранее время);
>
> s/obsoletes/obsolete/ -- чтоб было более понятно по-английски.

Thnks.

> >             python-modules-* -- много модулей, реально каждый пакет
> > содежит большую группу модулей, относящихся к примерно-одной тематике,
> > над автоматической кластеризацией я сейчас работаю;
> Я против избыточной "кластеризации" bundled модулей примерно по тем же
> причинам, по которым протестовал против отщепления модулей perl от
> штатной сборки.

Про перл не читал, избыточной не будет.

> По крайней мере, такое правило должно соблюдаться: если пользователь ставит
> apt-get install python python-doc
> он вправе расчитывать на наличие всех модулей, о которых написано в

Соблюдается. Правда, в перспективе, скорее python, python-modules, python-doc.
зависимость python / python-modules - временное решение.

> плюс подобранного вручную набора python-modules-* может быть полезна.
> Просто не нужно подвергать этому всех пользователей.

Я где-то предлагал иное?

> Вдобавок, без автоматического определения зависимостей
> возникнут проблемы у разработчиков, которым вместо одной зависимости
> на python = %__python_version как на всю платформу придётся смотреть,
> какие микропакеты реально нужны для работы.

Об этом было сказано в конце парграфа, вы просто не дочитали.

> >             python-tools-* -- различные инструменты для и на python,
> >                 например python-tools-idle;
> Это есть хорошо. Idle должен был отпочковаться.

Уже. Даже в сизифе лежит уже месяц.

> >             python-weak -- python с облегченными зависимостями,
> > допускающий провести совместную установку со старой версий pythonX.Y
>
> Я чую ненужную сложность.
> не будет установлен. Отпустите python-weak в пространство
> невоплощённых идей.

Не отпущу. Вам не мешает - мне нужно, некоторым другим - тоже. Кроме того, это работает.

> Вдогонку: если апгрейд модуля/приложения требует python = 2.3, почему
> бы не иметь в дистрибутиве python23, который благополучно вытянется,
> если он такое предоставляет? У нас уже организовано так несколько
> семейств пакетов, стоит ли здесь изобретать велосипеды?

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

> Сделайте исключение. Слишком многие знают старика под этим именем.

Provides: tkinter. Не вижу проблем.


>
> >             2.2.1 Удаление старой версии
> >
> >                 apt-get install pythno
>
> Не уверен, что правильно понял.

Установка новой версии командой apt-get install python приведет
к сносу старой версии, из-за существующего между ними конфликта.


>
> >     4.  В параметре GROUP спека должен быть указан
> > Development/Python/Modules;
>
> Что же тогда останется в Development/Python? :)
> Присоединяюсь к уже высказанному мнению, что в новой группе нет нужды.

Порядка 20ти пакетов самого пакета python, различные python-tools для разработки.
Уже высказанное мнение, звучало, помнится, как "если она действительно нужна, то будет создана".

> >             Зависимости на пакеты с другими модулями python надо
> > прописывать как
> >
> >                 Requires: python%__python_package_version-<anotherModule>
>
> Хотелось бы здесь поиметь автоматику...

Мы думаем над этим.

> Hint от соразработчика perl.{req,prov}, поимевшего кучу головной боли с
> синтаксисом Perl: в скриптах на Python, хвала ему и его разработчикам,

[skip]

> > '/' для получения относительного пути к файлу модуля (без суффикса
> .py) или каталогу с файлом __init__.py

Или файлу *zip, или *.so (с четырьмя разными доп.суффиксами), или вообще отсутвствующему
файлу, и наконец - еще есть перекрытая функция __import__ и приложения, 
изменяющие python_path. Причем, достаточно распространенным способом.

Так что, к сожалению, не все так просто, я уже попробовал. Пока что скрипт, эксплуатирующий
машину импорта самого python дает существенно более полный список зависимостей,
чем всякие игры с регексп. 

> >         6.  Симлинки на головные модули пакетов, устанавливаемых
> > многократно с специфичными версиями python должны управлятся посредством
> > alternatives, что позволяет избежать ситуации, с запуском головного

> Интересно, как вы этого добьётесь, если python и инструмент
> устанавливаются раздельно и используют отдельные конфигурации
> для alternatives (slave невозможен).

Пока что я этого добиваюсь, так как все такие пакеты мои и являются частью питона,
как например idle и pynche.

> Поддерживаю. Однако, python-doc отяжелеет от всего многообразия форматов.

Да, есть такая опасность. Пока что меня больше трогало то, что html-документация на
python это не все, и даже не самое интересное (удобное). Начнет тяжелеть - будем решать.
Что до info vs html ... Почему-то мне info ближе.

> Не стоит. Python - скриптовый язык, и пусть модули сохраняют
> скриптовый вид. Если нужна "компактность, компактность, компактность",
> пользуйтесь zip-ованными архивами, которые поддерживает python 2.3

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

> Кто-нибудь вообще проверял работоспособность python на одних
> .py[co] без исходника? Отладка точно пострадает. Что-нибудь ещё?

Я. Уже полгода, каждый день проверяю. На домашней машине некоторые пакеты пересобраны таким
образом. Отладка не страдает, других проблем нет. Единственная
большая проблема - нужно знать что ты ставишь и зачем, причем основная тонкость не отсутствие
_исходника_, без него-то все работает на ура, основная тонкость pyc vs pyo. Если сервер "продакшн продакшн
и никакой отладки" то ставим pyo и все ОК. Если появляется отладка - то, похоже, придется ставить и pyc и pyo
в основном пакете. 

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