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, как у людей? > Замечание 1: Более строго было бы использовать имя pythonX.Y-1, > но тут сложилась некая традиция, не уверен, что хорошая; Это какой-то ментальный блок, существующий со времён kernelXY, а то и раньше. -------------- лирическое отступление -------------------- Ещё раз, для всех, кого тянет придумать новый причудливый суффикс для зашифровывания номера версии, чтобы никто не догадался: точку в имени пакета использовать МОЖНО и желательно. Подчёркивание между собственно именем и номером версии как частью имени использовать можно, но нежелательно (дело эстетики, как в случае с libtool_1.x: без подчёркивания становится трудночитабельно). Дефис AKA минус в именах пакетов использовать НЕЛЬЗЯ, это грех перед Богом, за который вас заставят 1000 лет пересобирать пакеты в чистилище. ---------------------------------------------------------- > 8. Новая схема сборки допускает решение, при котором в дистрибутив > входят две и более версии языка python с некоторыми модулями, > пересобранными под несколько версий. Такое решение может быть > использованио исключительно в ситуации, когда один из > необходимых пакетов дистрибутива не может быть пересобран с > последней версией python (например, Zope, хотя до сих пор этого > удавалось избежать). В этом случае подлежат пересборке > модули, требуемые этим пакетом и не более того. Пересборка > модулей ведется так, что бы запуск rpm на пересборку > _без_указания_ каких-либо ключей порождал валидный пакет для > pythonMN, снабженный префиксом python-moduleMN; Поддерживаю. > Замечание 3: Такая пересборка может приводить к появлению в > репозитории нескольких почти идентнчных файлов src.rpm c > пакетами модулей для python разных версий. Хотя это может > показаться странным, необходжимо учитывать следующее > обстоятельство: форк есть форк. И если в момент форка некий > модуль test-u.v.w можно было пересобрать для обеих версий, > то модуль test-u.v.w+n, при достаточно большом n (в случае > некоторых модулей ~1), скорее всего, нет: новые фичи в питон > для того и вводятся, чбы их использовать, и примеров я могу > привести достаточно много; Поддерживаю. > 4. Новая схема сборки модулей гарантирует (зависмостямb) > невозмиожность установки модулей от старых версий python с его > новыми версиями По-моему, слишком жёсткое ограничение. Нужно решить лишь такую задачу: если есть зависимость между модулями, эта зависимость должна учитывать версию python ABI. Как этого можно достичь, я писал. > (по крайней мере на уровне минорных версий, > нужно ли затрагивать сабминоры - вопрос открытый, выйдет > python2.3.4 - посмотрим); Я думаю, можно полагаться на неявное обязательство разработчиков Python не ломать ABI между микро-релизами. > Я медленно, но верно, пилю питон на части. В этом процессе главное -- чувство меры ;) > Новый пакет будет состоять > примерно из следующих частей : > > python, python-base -- минимальная установка питона, достаточная > для его работы, практически не содержит модулей; Я правильно понял, что python это "панама", которая тянет python-base и python-modules? > python-obsoletes -- пакет, содержащий фрагменты python, которые > объявлены устаревшими (например, rotor.py) или несекъюрными > (он же, в более ранее время); s/obsoletes/obsolete/ -- чтоб было более понятно по-английски. > python-modules -- псевдопакет, содержащий зависимости на все > модули питон, рекомендованные к установке (не рекомендован, > в частности, пакет python-obsoletes); > > python-modules-* -- много модулей, реально каждый пакет содежит > большую группу модулей, относящихся к примерно-одной > тематике, над автоматической кластеризацией я сейчас > работаю; Я против избыточной "кластеризации" bundled модулей примерно по тем же причинам, по которым протестовал против отщепления модулей perl от штатной сборки. По крайней мере, такое правило должно соблюдаться: если пользователь ставит apt-get install python python-doc он вправе расчитывать на наличие всех модулей, о которых написано в Library Reference (за исключением тех, что в -obsolete: шоб знал, дурилка!). Иначе у пользователя, непосвящённого в премудрости дистрибутива, возникнет ощущение, что ему "недоложили". Возможность установки python-base как интерпретатора без модулей плюс подобранного вручную набора python-modules-* может быть полезна. Просто не нужно подвергать этому всех пользователей. Вдобавок, без автоматического определения зависимостей возникнут проблемы у разработчиков, которым вместо одной зависимости на python = %__python_version как на всю платформу придётся смотреть, какие микропакеты реально нужны для работы. > python-tools-* -- различные инструменты для и на python, > например python-tools-idle; Это есть хорошо. Idle должен был отпочковаться. > python-weak -- python с облегченными зависимостями, допускающий > провести совместную установку со старой версий pythonX.Y Я чую ненужную сложность. При условии, что во всех модулях прописана зависимость на python = %__python_version, установка legacy python при апгрейде произойдёт автоматически, если это будет нужно. Если все модули в системе обновляются на новый ABI в тот же присест, legacy python не будет установлен. Отпустите python-weak в пространство невоплощённых идей. Вдогонку: если апгрейд модуля/приложения требует python = 2.3, почему бы не иметь в дистрибутиве python23, который благополучно вытянется, если он такое предоставляет? У нас уже организовано так несколько семейств пакетов, стоит ли здесь изобретать велосипеды? > tkinter -- это tkinter. Возможно, будет переименован в python-modules-tkinter; Сделайте исключение. Слишком многие знают старика под этим именем. > 2.2.1 Удаление старой версии > > apt-get install pythno Не уверен, что правильно понял. > 4. В параметре GROUP спека должен быть указан Development/Python/Modules; Что же тогда останется в Development/Python? :) Присоединяюсь к уже высказанному мнению, что в новой группе нет нужды. > Зависимости на пакеты с другими модулями python надо прописывать как > > Requires: python%__python_package_version- Хотелось бы здесь поиметь автоматику... Hint от соразработчика perl.{req,prov}, поимевшего кучу головной боли с синтаксисом Perl: в скриптах на Python, хвала ему и его разработчикам, совпадение регулярного выражения ^(import|from) даёт стопроцентную гарантию безусловного включения другого модуля. Имя модуля отделено от найденного ключевого слова "символами пустоты" и состоит из ASCII alphanumerics, знаков подчёркивания и точек, которые нужно заменить на '/' для получения относительного пути к файлу модуля (без суффикса .py) или каталогу с файлом __init__.py > 6. Симлинки на головные модули пакетов, устанавливаемых многократно > с специфичными версиями python должны управлятся посредством > alternatives, что позволяет избежать ситуации, с запуском > головного модуля с неправильным питоном (так как alterantaives > изменит симлинк на tool одновременно с изменением симлинка на > python, а кто запускает tool не из /usr/bin - тот, > предположительно, знает, что делает). Альтернативный > альтернативам вариант - изменение записи в > #! - представляется трудоемким (хотя оптимизировать, конечно, > можно) и излишним (альтернативы решают проблему); Интересно, как вы этого добьётесь, если python и инструмент устанавливаются раздельно и используют отдельные конфигурации для alternatives (slave невозможен). Тут опять хочется предложить $PYTHON_VERSION и wrapper'ы в пакете -common по примеру autoconf и иже с ним. Так и idle можно обернуть, и всё остальное. > 7. Именование пакетов: я не сталкивался, пока, с прикладными > пакетами, которые не входили бы в python (как например IDLE), но > требовали бы (от меня) возможности сборки с каждым из > альтернативных питонов. Честно говоря, разводить зоопарк с Zope > для каждого питона - крайне неразумно. Я предполагаю возможность > появления необходимости сборки с одним из альтернативных питонов > (в случае с Zope избежать этого удавалось с некоторым > напряжением), но и в этом случае мы будем иметь дело только с > одним пакетом (правда, в этом случае в заголовке стартового > модуля потребуется-таки вписать путь к правильному питону). > Поэтому какое-либо префиксирование кажется излишним. Поддерживаю. > Поддерживаю полиси я, Андрей Орлов, мантейнер пакета python & Zope. > Я же обладаю (наверно) каким-то решающим голосом. Почему я? Потому > что логично поручить это мантейнеру python. Будет другой мантейнер > python - видимо, он же будет рулить и полиси. Почему решающим? > Потому что должен же кто-то выбрать из двух стогов сена один ;), а я > достаточно туп и ленив, чбы : > > a) Не делать лишних шагов; > > b) Не вдаватся в многочисленный тонкости: лучше > удовлетворительное решение сегодня, чем замечательное - > через год (тем более, что через год оно так и так будет); IMHO, Ваше самоуничижение преувеличено ;) > Q9: Почему питонов много, а python-doc - один. > > A9: Черт его знает. До недавнего обращения мантейнера python-doc с > просьбой забрать пакет я об этом не задумывался, и на самом деле > было даже два python-doc > - второй в рамках python23 и под названием python23-info. Наверно, > держать доки под каждый python все-таки неразумно и python23-info > откочует в python-doc. Поддерживаю. Однако, python-doc отяжелеет от всего многообразия форматов. > Q10: Одно время говорили о разрезании пакетов на подпакеты с модулями > py, pyo, pyc, что в этом направлении делается и на что это будет > похоже? И, кстати, когда это начнется? > > A10: Эксперименты ведутся уже сейчас, но это с собой несет столько > подводных камней, что не является частью настоящего перехода к новой > схеме питоновских модулей. Тем не менее некоторые вопросы могут быть > отвечены уже сейчас: > > 1. Всегда будет возможность установить файлы py, pyc и pyo, так > как все они имеют свою, очень важную, область применимости. > > Замечание про файлы pyc & pyo: > > - Установка только файлов py, pyc - при старте питон с > ключом -O (работа с оптимизированными файлами > байткода) будет приводить к перекомплиции, что > непохоже на оптимальную работу; > > - Установка только файлов py (выборочная), pyo - при > старте без ключа -O имеющиеся в наличии файлы pyo > будут игнорироваться, поэтому потребуется установко > py для всех модулей, хотя имеет смысл только > выборочная установка в целях отладки, в тоже время, > при старте с ключом -O нормальная отладка > невозможна; > > - Установка только pyc - работа с ключом -O > (оптимизированная) невозможна; > > - Установка только py - перекомпиляция при каждом > старте и серъезный объем на диске; > > Чбы еще более напугать желающих неподумавши выбросить файлы > pyc, добавлю: Zope, в норме, стартует два раза: рестарт > делается при отсутствии отладочного режима с ключом -O. > > И, наконец, если кто не знает: "а еще их можно зиповать", > фича новая (python23), непроверенная, но для серверов > приложений, типа Zope, которые однажды стартуют и месяц > работают, довольно перспективная. В некоторых вариантах > использования (Live CD например), просто незаменимая. > > > 2. Видимо, пакеты будут разрезаны на python- & > python--src, при этом python- содержит файлы > pyo и (или) pyc, а ...-src - файлы py. Не стоит. Python - скриптовый язык, и пусть модули сохраняют скриптовый вид. Если нужна "компактность, компактность, компактность", пользуйтесь zip-ованными архивами, которые поддерживает python 2.3 Кто-нибудь вообще проверял работоспособность python на одних .py[co] без исходника? Отладка точно пострадает. Что-нибудь ещё? Спасибо Андрею и Алексею за недюжинную работу. -- Stay tuned, MhZ JID: mhz@altlinux.org ___________ life, n.: Learning about people the hard way -- by being one.