Re: [devel] Python Modules Policy:

["Алексей Любимов" <avl@l14.ru>]

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<N>-ModuleName из исходника вида python-ModuleName
>>>      
>>>
>>Если будет строго выполнен пункт 2, то это имхо лишнее...
>>Уж если у кого дойдут руки, то можно делать пакеты python22-ModuleName
>>то есть схема пакет и compat-пакет, а не ПакетВерсия1 и ПакетВерсия2
>>    
>>
>См. выше про автомат.
>root, root
>
Теперь понятно.

>  
>
>>>5. В полиси для питоньих модулей вносится обязательный
>>> Requires: python = %<pversion>, где %<pversion> совпадает с
>>> %__python_version того питона, для которого производилась сборка.
>>>      
>>>
>>Это понятно.
>>    
>>
>ldv@ уже предложил решение, которое, вроде бы, не хуже по последствиям,
>но автоматизируется. Прокомментируйте его, пожалуйста.
>
Менять макросы rpmbuild?
По моему это источник еще одной головной боли.
Опять будет куча unmets, как это происходит при любом чихе сейчас с 
перлом и прочими.
Но самое главное, будет непрозрачное повдение rpm при сборке пакета.
Проблема с с зависимостями питона не так серьезна, чтобы рубить с плеча.
По моему все очень просто - поставил Requires: python = %<pversion> и 
получил нужную зависимость.
А не поставил - получил более свободный и универсальный вариант. Всем 
хорошо и никому плохо.

>>>Предлагается подумать над следующими двумя полиси:
>>>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<version> ...
>>> и могут таскать за собой байткод.
>>>      
>>>
>>В скриптах? и вы согласны переписывать все скрипты в модуле при переходе 
>>версий???
>>    
>>
>Если эти _скрипты_ завязаны на данную версию питона: да, согласен.
>Но, мой опыт (сборки 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) и даже иметь страничку в 
конфигураторе (которого нет).
Вобщем пока все слишком непонятно, чтобы обсуждать рамки.

>>Незрело, конечно, но по моему, вполне может получится...
>>    
>>
>Показывайте.
>
попробую ближе к выходным.