[devel] Python Modules Policy:

[Алексей Любимов]

>См. письмо про RFC.
>Андрей Орлов в джаббере высказал мнение, что, возможно, стоит пойти по
>другому пути, с доводкой до ума libAltDist. Возможно, это тоже путь.
>Более подробно он выскажется сам.
>
>Сейчас, я так понимаю, нужно выслушать мнение тех, кто реально будет эти
>самые модуля собирать (и использовать).
>  
>
По моему, все трое уже высказались. :)

>>>ldv@ уже предложил решение, которое, вроде бы, не хуже по последствиям,
>>>но автоматизируется. Прокомментируйте его, пожалуйста.
>>>      
>>>
>>Менять макросы rpmbuild?
>>По моему это источник еще одной головной боли.
>>Опять будет куча unmets, как это происходит при любом чихе сейчас с 
>>перлом и прочими.
>>    
>>
>См. моё решение. F*cking magic, но таки "работает для меня". Причем,
>если нужно, добавки происходят относительно безболезненно, как _мне_
>_кажется_ в _настоящее время_
>  
>

все, что связано с rpm должно пройти проверку на совместимость с 
сандменом. Иначе лично мне нет смысла разводить драку.
Вроде проблем не должно быть...

>>Но самое главное, будет непрозрачное повдение rpm при сборке пакета.
>>Проблема с с зависимостями питона не так серьезна, чтобы рубить с плеча.
>>По моему все очень просто - поставил Requires: python = %<pversion> и 
>>получил нужную зависимость.
>>    
>>
>Все автоматом происходит. Аллилуйя! :-)
>  
>
не пугайте.

>>А не поставил - получил более свободный и универсальный вариант. Всем 
>>хорошо и никому плохо.
>>    
>>
>Но для модулей такая зависимость реально нужна.
>
Далеко не во всех питон-программах есть модули, но используются модули 
почти везде.
Кроме того иногда нет нужды в строгих зависимостях. Спец софт или 
девелоперский вариант вполне допускает такие фокусы.

>Да, конечно. Но они как правило говорят просто
>
>import smth
>
>а уж откуда этот smth потянется - забота того питона, при помощи
>которого эта прога выполняется. Сменится питон, сменится и место.
>Но это никак не заденет саму прогу (вопросы совместимости разных
>версий _языка_ оставим в стороне)
>  
>

а зависимости в пакете на эти модули кто будет ставить и каким образом?
Если программа собрана под питон23, то и зависиость будет python23-smth. 
такой вариант работает.

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

>
>	* имеется Twisted (благо, он действительно имеется, собран и
>	  подходит для примера)
>	* при сборке образуются следующие модули:
>		* python<NN>-Twisted - сборище _модулей_ из Twisted
>		  (вероятно, я распилю этот пакет на Twisted,
>		  Twisted-web, Twisted-gtk итп)
>		* python-Twisted-utils - вещи, которые, грубо говоря,
>		  идут в /usr/bin/ и от конкретной версии питон не
>		  зависят
>		* python-Twisted-doc и всё остальное прочее барахло,
>		  которое потребно лишь девелоперам
>  
>


Вариант

pyhon22-Twisted  полный коплект в  варианте для pyhon22
pyhon22-doc

pyhon23-Twisted  полный коплект в  варианте для pyhon23
pyhon23-doc

+ Альтернатива slave к питону.


>>>Без разможения пакетов - плохо, по-моему. Я сейчас периодически сам
>>>заглядываю в твистедовые потроха, чтобы понять, что же имелось ввиду в
>>>доке.
>>>      
>>>
>>я имею в виду не молчаливое удаление *.py как это сделали с *.la, а 
>>некий инструмент, селектирующий систему после (и в процессе) установки.
>>    
>>
>Ну, можно, конечно, оформить это как %def_without python_source,
>но, гхм... В общем, думать надо.
>
ага.

>>То есть один дистрибутив расщепился на 15 пакетов, что уже много.
>>    
>>
>В общем, пилить его надо. Не знаю, какова ситуация именно с Zope, но
>по зависимостям полный Twisted, если его паковать правильно, тянет,
>н-р, pygtk, который тянет GTK+/Glade, а что начинается дальше, в общем,
>рассказывать не надо, да? :-) И это несмотря на то, что я, в общем,
>захотел безобидной вещи, простенький серверок поверх http запустить :-)
>"Абидна, да-а?! Ничего нэ сдэлал, да-а?!"
>

Зависимости, это как раз причина для распила. В zope я этой причины не 
пронаблюдал. Может, плохо смотрел.

>Кстати, насчет .pyc vs .pyo. В .pyc есть какой-нибудь смысл при наличии
>.pyo (кроме отдельно оговоренных единичных случаев)?
>  
>
Андрей явно более осведомлен.
По моему не нужны pyc

>>Вот, что дополнительно используется только на www.linux-os.ru (ничего 
>>такого специфичного)
>>
>>ArchExample
>>    
>>
>...
>Супер.
>
ерунда. он в плоне как раз и не установлен.

>>а какой смысл в разделении? не проще ли собрать два пакета вместо 
>>четырех, полностью их скомпилировать и в дальнейшем сопровождать?
>>    
>>
>Очень просто.
>Когда я ставлю/запускаю /это/ я говорю
>
>twisted -ny server_start.py (или вообще .tap)
>
>При этом версия питона "по умолчанию" мне, в общем, по барабану
>(ну, при условии, что у меня код написан так, что его реально можно
>таскать. Если таскать нельзя, то в том месте, которое таскать нельзя
>стоит: "нужен именно pythonX.Y!" и старт обламывается). При этом мне не
>нужно ни альтернатив (которые, вообще-то, не самостоятельные в данном
>случае, а slave'ы на python), ничего специального. Выбор версии питона
>происходит в момент пробегания по /usr/bin/python -> ... ->
>/usr/bin/pythonX.Y
>  
>
ну так и ставить нужную версию.
twisted23 или twisted22 если так уж не хочется альтернатив.