From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Andrey Orlov To: ALT Devel discussion list Date: Mon, 23 Feb 2004 09:50:40 +0300 User-Agent: KMail/1.5.4 References: <200402222232.27464.cray@neural.ru> <20040222214059.GA1905@av1046.comex.ru> In-Reply-To: <20040222214059.GA1905@av1046.comex.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Message-Id: <200402230950.40967.cray@neural.ru> Subject: [devel] Re: A: =?koi8-r?b?8M/MydPJ?= ( =?koi8-r?b?0SDT18XMINfTxSDXz8XEyc7P?= ) + FAQ X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 06:49:25 -0000 Archived-At: List-Archive: List-Post: 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- > > Хотелось бы здесь поиметь автоматику... Мы думаем над этим. > 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 --- ----------------------------------------