Re: [devel] Python Modules Policy:

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

Alexey Morozov пишет:

>On Thu, Feb 12, 2004 at 06:22:14PM +0300, Алексей Любимов wrote:
>  
>
>>>См. письмо про RFC.
>>>Андрей Орлов в джаббере высказал мнение, что, возможно, стоит пойти по
>>>другому пути, с доводкой до ума libAltDist. Возможно, это тоже путь.
>>>Более подробно он выскажется сам.
>>>
>>>Сейчас, я так понимаю, нужно выслушать мнение тех, кто реально будет эти
>>>самые модуля собирать (и использовать).
>>>      
>>>
>>По моему, все трое уже высказались. :)
>>    
>>
>Где? Я видел реакцию на мой RFC исключительно от Андрея. И то, в общем,
>неполную, а так "навскидку".
>  
>
Молчание, это тоже мнение.
Лично уменя яду не набралось, чтобы возопить, а плюсов я пока тоже не 
пронаблюдал.
см далее.

>>>См. моё решение. F*cking magic, но таки "работает для меня". Причем,
>>>если нужно, добавки происходят относительно безболезненно, как _мне_
>>>_кажется_ в _настоящее время_
>>>      
>>>
>>все, что связано с rpm должно пройти проверку на совместимость с 
>>сандменом. Иначе лично мне нет смысла разводить драку.
>>Вроде проблем не должно быть...
>>    
>>
>Ну, я попробую утащить все это дело к Мише, и собрать в хэшере.
>Благо, там немного...
>  
>

вариант.

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

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

>>Кроме того иногда нет нужды в строгих зависимостях. Спец софт или 
>>девелоперский вариант вполне допускает такие фокусы.
>>    
>>
>Стоп, какие фокусы?
>  
>
да просто собрал пакет и отдал его редхатчику. у него же нет таких 
пакетов в конце концов.
или девелоперская версия с непонятными пока еще зависимостями...



>>>Да, конечно. Но они как правило говорят просто
>>>import smth
>>>а уж откуда этот smth потянется - забота того питона, при помощи
>>>которого эта прога выполняется. Сменится питон, сменится и место.
>>>Но это никак не заденет саму прогу (вопросы совместимости разных
>>>версий _языка_ оставим в стороне)
>>>      
>>>
>>а зависимости в пакете на эти модули кто будет ставить и каким образом?
>>    
>>
>Очень просто
>Requires: python-pyserial = <требуемая версия>
>Оно автоматом предоставляется.
>В смысле,
>pythonXY-pyserial предоставляет pyserial
>Если у программы нет предпочтений по поводу, какой питон ей
>использовать, она просит именно "общую версию".
>
>>Если программа собрана под питон23, то и зависиость будет python23-smth. 
>>такой вариант работает.
>>    
>>
>Ну, "программа", в общем случае, ни под что не собрана, она сама по себе
>программа. С #!/usr/bin/env python .. внутри. Как сделать так, чтобы
>она хотела python-Module1 python-Module2 python-Module3, и при установку
>в систему _еще_ одного питона, в _дополнение_ к существующему, автоматом
>притаскивались pythonXY-Module1, pythonXY-Module2 итп, я [пока] не знаю.
>  
>
так вот о том и речь.
с этой ерунды же все и началось, что при наличии нескольких питонов, (а 
это норма, учитывая необходимость пересборки всех модулей перед 
снесением старой версии)  зависимости получаются левыми...


>>а если "универсальный вариант", то получится тот же коленчатый вал, 
>>когда половина модулей в одном питоне, половина в другом, а программа 
>>импортит оба множества и с любым питоном не работает при полном 
>>непротиворечии в базе rpm.
>>    
>>
>Ну, надо что-то придумывать. Либо сказать, что те, кто держит у себя на
>машине сразу _два_ питона, должны делать всё руками и внимательно.
>Разница лишь в том, что предложенная мной схема _допускает_ возможность
>решения в случае, если питонов больше одного. Но на уровне: "надо -
>сделай сам". Хоть и предоставляет достаточно удобные [на мой взгляд ;-)]
>ручки конечному пользователю.
>  
>
да пока что "ручки" Орлова ничем не хуже. Что там, что там есть 
требование держать только один питон.
Чего тогда колготится?

>>+ Альтернатива slave к питону.
>>    
>>
>Альтернатива на _что_?
>  
>
на twisted. но это не обязательно, если поставить conficts друг на друга.

>  
>
>>>Ну, можно, конечно, оформить это как %def_without python_source,
>>>но, гхм... В общем, думать надо.
>>>      
>>>
>>ага.
>>    
>>
>Ну, тогда, когда нужны .py, тянем .src.rpm и пересобираем? Так что-ли?
>  
>
Я бы просто клал *.py в пакет *.doc в /usr/share/doc/src/путь от корня/*.py
Захотел исходничков - поставил *.doc и посмотрел.

Хотя в общем случае - не дело rpm такие слои нарезать. Дело рпм ставить 
пакеты и следить за минимумом зависимостей. И все...

>>>Супер.
>>>      
>>>
>>ерунда. он в плоне как раз и не установлен.
>>    
>>
>Меня список впечатлил. Как говорится, и шо ви с этог'о имеете? :-)
>  
>
половина, это зависимости plone + рассылка postboxer + форум cmfboard с 
зависимостями + клиент для imap почты + wiki.
И это все...



>  
>
>>>При этом версия питона "по умолчанию" мне, в общем, по барабану
>>>(ну, при условии, что у меня код написан так, что его реально можно
>>>      
>>>
>...
>  
>
>>>случае, а slave'ы на python), ничего специального. Выбор версии питона
>>>происходит в момент пробегания по /usr/bin/python -> ... ->
>>>/usr/bin/pythonX.Y
>>>      
>>>
>>ну так и ставить нужную версию.
>>twisted23 или twisted22 если так уж не хочется альтернатив.
>>    
>>
>Ну, это да, конечно. Просто если держать обе сразу (у меня были такие
>шальные мысли, по крайней мере, поначалу), то тогда их (программы)
>приходится разводить по именам, городить альтернативы итп. А зачем,
>если они все равно одинаковые? Поэтому я и поступил таким вот образом.
>
да конечно проще просто  поставить конфликт друг на друга. в 99% это 
будет самое умное решение.