From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <402B3987.80901@l14.ru> Date: Thu, 12 Feb 2004 11:29:59 +0300 From: =?KOI8-R?Q?=E1=CC=C5=CB=D3=C5=CA_=EC=C0=C2=C9=CD=CF=D7?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.4) Gecko/20031103 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: ALT Devel discussion list Subject: Re: [devel] Python Modules Policy: References: <87znbsh12p.fsf@pc349.belcaf.minsk.by> <200402100025.27343.cray@neural.ru> <40280A53.7090301@l14.ru> <200402100301.33551.cray@neural.ru> <40288B88.2060303@l14.ru> <20040210080400.GG13525@pyro.hopawar.private.net> <4028A20E.2030302@l14.ru> <20040210101551.GO13525@pyro.hopawar.private.net> <4028FDF6.3070802@l14.ru> <20040211095023.GV13525@pyro.hopawar.private.net> In-Reply-To: <20040211095023.GV13525@pyro.hopawar.private.net> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit 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: Thu, 12 Feb 2004 08:32:51 -0000 Archived-At: List-Archive: List-Post: Alexey Morozov пишет: >On Tue, Feb 10, 2004 at 06:51:18PM +0300, Алексей Любимов wrote: > > >>>Не вопрос. Мы с Андреем уже договорились (в джаббере) до того, что >>> >>>1. Он проставляет Obsoletes: pythonN в python{N+1} или делает >>> аналогичные изменения, о точном решении будет сообщено >>> дополнительно ориентировочно в конце недели. >>>2. _Одновременная_ сборка пакетов под разные версии питона является >>> на данный момент ненужной ввиду своей трудоемкости. >>> >>> >>реально это означает, что поддержка python22 отменяется. >>Или, проще говоря, на зоп* в сизифе и все, что посложнее "hello world" >>можно забить. >> >> >Нет. Их можно будет собирать "неодновременно", т.е. в два прохода. >Может быть, даже автоматом. > А, так это в том смысле, что из одного спека за один проход собирать пакеты для всех питонов трудоемко? Это как раз само собой разумеется. Раз так, то на зоп в сизифе и все, что посложнее "hello world" можно (и нужно) не забивать :) > > >>>3. Андрей думает над целесообразностью сборки пакетов вида >>> python-ModuleName из исходника вида python-ModuleName >>> >>> >>Если будет строго выполнен пункт 2, то это имхо лишнее... >>Уж если у кого дойдут руки, то можно делать пакеты python22-ModuleName >>то есть схема пакет и compat-пакет, а не ПакетВерсия1 и ПакетВерсия2 >> >> >См. выше про автомат. >root, root > Теперь понятно. > > >>>5. В полиси для питоньих модулей вносится обязательный >>> Requires: python = %, где % совпадает с >>> %__python_version того питона, для которого производилась сборка. >>> >>> >>Это понятно. >> >> >ldv@ уже предложил решение, которое, вроде бы, не хуже по последствиям, >но автоматизируется. Прокомментируйте его, пожалуйста. > Менять макросы rpmbuild? По моему это источник еще одной головной боли. Опять будет куча unmets, как это происходит при любом чихе сейчас с перлом и прочими. Но самое главное, будет непрозрачное повдение rpm при сборке пакета. Проблема с с зависимостями питона не так серьезна, чтобы рубить с плеча. По моему все очень просто - поставил Requires: python = % и получил нужную зависимость. А не поставил - получил более свободный и универсальный вариант. Всем хорошо и никому плохо. >>>Предлагается подумать над следующими двумя полиси: >>>6. Программы на python, не зависящие от конкретной версии питона >>> (epydoc, python-doc-tools), собираются _без_ байткода и, >>> соответственно, без привязки к точной версии питона, используется >>> #!/usr/bin/env python ... >>> >>> >>А где же они лежать будут? по логике все равно в python?.?/site-packages/ >> >> >Нет. Питоньи скрипты (н-р, python-doc-tools) лежат не там. >epydoc тоже лежит не там, вроде бы. Если нужно подумать над >"версионно-независимом" каталоге для питона, его можно организовать, >насколько я понимаю. > Ну так это же просто программы на питоне. Однако все равно любая такая прога сложнее трех строк зависит от импортируемых модулей из python?.?/site-packages/. То бишь 99,9% пакетов все равно потребуют питона с набором дополнений под его версию. Плохо представляю себе, как должны выглядеть зависимости такого пакета. Причем все равно такие программы запросто не будут работать под тем или иным питоном даже при наличии нужных модулей. Разве не проще разобраться с неработоспособностью пакета, увидев в репорте gdesklets22, а не gdesklets? Да и класть только некомпилированные модули в пакет, это фактически ухудшить качество пакета. Скомпилировать его юзер уже не сможет и ему будет выгоднее просто скопировать содержимое к себе в хоум и запускать оттуда. На этот слакварный вариант целимся? >>По моему, это излишнее усложнение. Поддерживается один питон, так и >>пусть поддерживается. >>Наоборот скорее от сорцов надо избавлятся (только без размножения >>пакетов). >> >> >Без разможения пакетов - плохо, по-моему. Я сейчас периодически сам >заглядываю в твистедовые потроха, чтобы понять, что же имелось ввиду в >доке. > > я имею в виду не молчаливое удаление *.py как это сделали с *.la, а некий инструмент, селектирующий систему после (и в процессе) установки. А под размножением пакетов я имею в виду следующее: что у нас сегодня есть из _одного_ пакета/дистрибутива Zope Zope-DateTime - Date and time representation Zope-DocumentTemplate - DocumentTemplate - DTML template engine Zope-Modules - Zope modules used by ZServer and PCGI Zope-RestrictedPython - RestrictedPython for protected environments Zope-StructuredText - StructuredText - automatic text markup Zope-TAL - TAL - XML template engine Zope-Testing - Testing environment for Zope components Zope-ZHome - ZHome - sample home directory of ZServer Zope-ZODB - ZODB and BTrees - object-oriented database ZODB Zope-ZPublisher - ZPublisher - Zope query proceeding Zope-ZServer - ZServer - Zope Application Server Zope-ZUtils - ZUtils - Zope startup and maintenance scripts Zope-core - Libraries used by Zope and ZODB Zope-ReST - ReST - ReStructuredText Document for Zope Zope-reStructuredText - reStructuredText - enhanced automatic text markup То есть один дистрибутив расщепился на 15 пакетов, что уже много. Представим себе еще расщепление на *.py *pyc и *.pyo и получим 30/45 пакетов из одного дистра зопа. Добавим туда немножко косяков с автозависимостями в rpm и вполне можно бежать за веревкой... Замечу, что зоп, это здорово, но еще далеко не все. Вот, что дополнительно используется только на www.linux-os.ru (ничего такого специфичного) ArchExample CMFCalendar CMFQuickInstallerTool Epoz MailManager TranslationService ArchGenXML CMFCore CMFTopic Formulator PlacelessTranslationService UserTrack Archetypes CMFDefault CMFUserTrackTool GroupUserFolder PloneSearchBox ZWiki BTreeFolder2 CMFFormController Localizer PloneWebMail CMFActionIcons CMFMessage MPoll PortalTransforms generator CMFBoard CMFPlone DCWorkflow MailBoxer PortalTransport validation Перемножим и это на два/три пакета и получим совсем кашу. >>>7. Программы, имеющие такую привязку (н-р, идущие вместе с конкретной >>> версией питона) иcпользуют #!/usr/bin/env python ... >>> и могут таскать за собой байткод. >>> >>> >>В скриптах? и вы согласны переписывать все скрипты в модуле при переходе >>версий??? >> >> >Если эти _скрипты_ завязаны на данную версию питона: да, согласен. >Но, мой опыт (сборки twisted) показывает, что достаточно внятно разделить: >вот этот пакет - модул{ь,и}, он[и] привязан[ы] к версии питона, а вот >это - скрипты [из /usr/bin], которые одинаково хорошо работают как с >твистедом, собранным под 2.2, так и с твистедом, собранным под 2.3 > > а какой смысл в разделении? не проще ли собрать два пакета вместо четырех, полностью их скомпилировать и в дальнейшем сопровождать? >>>8. Некоторое время назад Андрей предлагал в "боевых" пакетах таскать >>> только байткод, а .py заворачивать в отдельные пакеты "для >>> интересующихся" (по моему разумению, по схеме, напоминающей то, что >>> делает Алекс Отт для емакса, хотя _это мои предположения_) >>> >>> >>И наплодить еще дубликатов-пакетов пачку. >> >> >У Андрея были практические соображения, почему в боевую версию НЕ надо >пихать сорцы. С другой стороны, мой небольшой практический опыт >показывает, что сорцы _иногда_ нужны. > > мой опыт говорит, что сырцы нужны всегда или почти всегда. вот сейчас пытаюсь завести науменовскую crm 2.3 без сырцов и ни хрена не получается. версия 2.2 с сырцами завелась практически сразу, потому как из них было видно, что конкретно не устраивает программу. >>У меня вот зреет какое то общее средство под кодовым названием stripper. >> >> >... > > >>Также можно поставить правила по умолчанию и они будут срабатывать при >>установке пакетов сами. >> >> >Это никак не упихивается в рамки distutils? > > /usr/lib/python2.3/site-packages/libaltdist.py ? не похоже. Эта штука должна по идее сопровождать установленную систему все время его существования (как апт или control) и даже иметь страничку в конфигураторе (которого нет). Вобщем пока все слишком непонятно, чтобы обсуждать рамки. >>Незрело, конечно, но по моему, вполне может получится... >> >> >Показывайте. > попробую ближе к выходным.