From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <402B9A26.3010705@l14.ru> Date: Thu, 12 Feb 2004 18:22:14 +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: <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> <402B3987.80901@l14.ru> <20040212100301.GG16285@pyro.hopawar.private.net> In-Reply-To: <20040212100301.GG16285@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 15:25:07 -0000 Archived-At: List-Archive: List-Post: >См. письмо про RFC. >Андрей Орлов в джаббере высказал мнение, что, возможно, стоит пойти по >другому пути, с доводкой до ума libAltDist. Возможно, это тоже путь. >Более подробно он выскажется сам. > >Сейчас, я так понимаю, нужно выслушать мнение тех, кто реально будет эти >самые модуля собирать (и использовать). > > По моему, все трое уже высказались. :) >>>ldv@ уже предложил решение, которое, вроде бы, не хуже по последствиям, >>>но автоматизируется. Прокомментируйте его, пожалуйста. >>> >>> >>Менять макросы rpmbuild? >>По моему это источник еще одной головной боли. >>Опять будет куча unmets, как это происходит при любом чихе сейчас с >>перлом и прочими. >> >> >См. моё решение. F*cking magic, но таки "работает для меня". Причем, >если нужно, добавки происходят относительно безболезненно, как _мне_ >_кажется_ в _настоящее время_ > > все, что связано с rpm должно пройти проверку на совместимость с сандменом. Иначе лично мне нет смысла разводить драку. Вроде проблем не должно быть... >>Но самое главное, будет непрозрачное повдение rpm при сборке пакета. >>Проблема с с зависимостями питона не так серьезна, чтобы рубить с плеча. >>По моему все очень просто - поставил Requires: python = % и >>получил нужную зависимость. >> >> >Все автоматом происходит. Аллилуйя! :-) > > не пугайте. >>А не поставил - получил более свободный и универсальный вариант. Всем >>хорошо и никому плохо. >> >> >Но для модулей такая зависимость реально нужна. > Далеко не во всех питон-программах есть модули, но используются модули почти везде. Кроме того иногда нет нужды в строгих зависимостях. Спец софт или девелоперский вариант вполне допускает такие фокусы. >Да, конечно. Но они как правило говорят просто > >import smth > >а уж откуда этот smth потянется - забота того питона, при помощи >которого эта прога выполняется. Сменится питон, сменится и место. >Но это никак не заденет саму прогу (вопросы совместимости разных >версий _языка_ оставим в стороне) > > а зависимости в пакете на эти модули кто будет ставить и каким образом? Если программа собрана под питон23, то и зависиость будет python23-smth. такой вариант работает. а если "универсальный вариант", то получится тот же коленчатый вал, когда половина модулей в одном питоне, половина в другом, а программа импортит оба множества и с любым питоном не работает при полном непротиворечии в базе rpm. > > * имеется Twisted (благо, он действительно имеется, собран и > подходит для примера) > * при сборке образуются следующие модули: > * python-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 если так уж не хочется альтернатив.