From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <402BB39D.2040205@l14.ru> Date: Thu, 12 Feb 2004 20:10:53 +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: <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> <402B3987.80901@l14.ru> <20040212100301.GG16285@pyro.hopawar.private.net> <402B9A26.3010705@l14.ru> <20040212161525.GS16285@pyro.hopawar.private.net> In-Reply-To: <20040212161525.GS16285@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 17:13:49 -0000 Archived-At: List-Archive: List-Post: Alexey Morozov пишет: >On Thu, Feb 12, 2004 at 06:22:14PM +0300, Алексей Любимов wrote: > > >>>См. письмо про RFC. >>>Андрей Орлов в джаббере высказал мнение, что, возможно, стоит пойти по >>>другому пути, с доводкой до ума libAltDist. Возможно, это тоже путь. >>>Более подробно он выскажется сам. >>> >>>Сейчас, я так понимаю, нужно выслушать мнение тех, кто реально будет эти >>>самые модуля собирать (и использовать). >>> >>> >>По моему, все трое уже высказались. :) >> >> >Где? Я видел реакцию на мой RFC исключительно от Андрея. И то, в общем, >неполную, а так "навскидку". > > Молчание, это тоже мнение. Лично уменя яду не набралось, чтобы возопить, а плюсов я пока тоже не пронаблюдал. см далее. >>>См. моё решение. F*cking magic, но таки "работает для меня". Причем, >>>если нужно, добавки происходят относительно безболезненно, как _мне_ >>>_кажется_ в _настоящее время_ >>> >>> >>все, что связано с rpm должно пройти проверку на совместимость с >>сандменом. Иначе лично мне нет смысла разводить драку. >>Вроде проблем не должно быть... >> >> >Ну, я попробую утащить все это дело к Мише, и собрать в хэшере. >Благо, там немного... > > вариант. >>>>По моему все очень просто - поставил Requires: python = % и >>>>получил нужную зависимость. >>>> >>>> >>>Все автоматом происходит. Аллилуйя! :-) >>> >>> >>не пугайте. >> >> >Нет, Вы все-таки попробуйте :-) >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% это будет самое умное решение.