From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Andrey Orlov To: ALT Devel discussion list Subject: Re: [devel] =?koi8-r?b?88LP0svB?= =?koi8-r?b?INDBy8XUz9c=?=, =?koi8-r?b?08/ExdLWwd3JyA==?= .py Date: Sat, 17 Jan 2004 00:02:34 +0300 User-Agent: KMail/1.5.4 References: <20040113130237.GA2227@pyro.hopawar.private.net> <200401161810.40534.cray@neural.ru> <20040116195839.GD31943@pyro.hopawar.private.net> In-Reply-To: <20040116195839.GD31943@pyro.hopawar.private.net> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200401170002.34490.cray@neural.ru> 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: Fri, 16 Jan 2004 21:02:03 -0000 Archived-At: List-Archive: List-Post: On Friday 16 January 2004 22:58, Alexey Morozov wrote: > > Скомпиленный питоновский модуль нельзя разместить с другим путем. Так > > Но можно же задать при сборке собственно питона другое расположение > библиотечных путей, правда? Библиотечный путь тут не причем. Речь о пути к исходному файлу питона в момент компиляции. >> Андрей, я понимаю Вашу озабоченность проблемами сборки Zope. Но у меня > сейчас немного другие проблемы, не затрагивающие впрямую Zope. И я НЕ > претендую на универсальность моего решения. Я Zope привожу только как пример. Просто этот пример подтвержден другими людьми и мне есть на что сослатся. А так - проблемы могут возникнуть практически со всеми скриптами. > > > > Сухой остаток: я бы попросил ничего не менять, не разобравшись. > Именно это я и пытаюсь сделать. > > > Прекомпиляцию модулей лучше пока оставить, тем более что именно в > > контексте етого треда, ее изъятие _вашей_ проблемы не решит, из-за > > непериносимости _исходного_ кода на языке питон в _общем_ случае. > > Мне, все же кажется, что _мою_ проблему это решит замечательно, > поскольку те конкретные скрипты, о которых я веду речь, нормально > работают на всех последних версиях питона. Что же касается всех Я уже предлагал 2 варианта: 1. отменять байт-комплилицию для определенного каталога (надо только посотреть ка это лушче сделать) 2. не включать байт-код в пакет, если он не нужен. Ну и хрен с ним, что скопилился. > остальных python-скриптов в мире, то, как мне кажется, с принудительной > байт-компиляцией мы получаем _две_ проблемы вместо _одной_: > во-первых, возможны нюансы, касающиеся переносимости собственно кода > (но на это хоть диагностика будет внятная), У нас нет переносимости кода - мы пересобираем модули и пакеты при появлении нового питона, нового С, и т.п. > > во-вторых, возможны проблемы с переносимостью байткода как такового > (и я совершенно не уверен в том, как поведет себя питон, увидев > несовместимый байт-код). У нас нет перенесения байт кода. По вышеописанным причинам. В каждом пакете стоит требование определенного питона. Кроме того альтернативы, python22 & 23 скомпиены с разными путями, а модули для разных питонов ложаться в разные каталоги. И вообще, как я уже сказал, python22 в норме использоватся не должен вообще. > В данном треде я совсем НЕ РАССМАТРИВАЛ первую проблему, целиком > занимаясь исключительно второй. > > > Если вы считаете что _ваш_ пакет не должен содержать *pyc & *pyo - вы > > можете не _включать_ их в секцию files _вашего_ spec'а. А все > > Могу. Но, во-первых, для модулей, все же, _хочется_ включать байткод, > причем, откомпилированный именно тем питоном, который потом будет этот > модуль использовать (сейчас это, по факту НЕ ТАК, если вместо %__python > используется, скажем, python-2.3). Интересно, почему это не так? У меня это вроде как так. И на описанную вами ситуацию я ни разу не нарывался. Мбть что-то у вас подпраить надо? > А во-вторых, мне, все же, больше > нравится оперировать списком файлов, сформированных на этапе > setup.py install > > а не произвольными каталогами (хотя, возможно, это и относится к области > [неверных] личных предпочтений). А вы и оперируете этим списком. Просто фильтруете и раскладываете его по трем пакетам. Кроме того, если этот список содержит прекомпиленные модули - то чего же вы от них отказываетесть? А если он их не содержит - то как же они попадают в пакет, если вы используете этот список? Что-то вы тут меня запутать пытаетесь, похоже ;). > > Давайте, только прислушивайтесь к чужому мнению? > Как мне кажется, и так уже прислушиваюсь. Сорри, если кажется что я наезжаю - я просто не выспался и никак не могу уразуметь самого главного: в чем собственно проблема? Ну давайте я выкину из сизифа python22 - проблема пропадет? Если так, то представьте себе что я это сделал. > > 2. Перенос исходного кода из одной версии в другую может приводить к > > ошибкам, что отменяет возможность решения проблемы двух питонов за > > счет отказа от прекомпиленного кода; > > Нет. Это решение _другой_ проблемы. См. выше. Я тогда так и не понял о чем речь. Т.е. какую проблему вы пытаетесь решить > > 3. Сама проблема двух питонов является надуманной, так как никакой > > необходимости держать два питона на одной машине я не знаю; > > Андрей, выше Вы пишете о том, что при переезде с python-2.2 на > python-2.3 отвалилась большая часть Zope, и понадобилось ненулевое время > на исправление ситуации. В другом письме Вы (я все же надеюсь, что это > были Вы) пишете, что разработчики в своей деятельности должны > использовать самые модные наработки Я писал - самые современные, еще раз, не надо искажать мои слова. Именно поэтому я потратил это время, что бы очередной раз избавится от необходимости держать в дистрибутиве старый питон. И я не понимаю почему кто-то отказывается это делать. Переходить на новую версию питона все равно придется. То, что мы держим в сизифе python22 - это только в помощь тем, кто переходит. И я не услышал на свои прямые неоднократные вопросы в рассылке ни одного ответа, что у кого-то были непреодолимые трудности с этим переходом. Только вы зачем-то пытаетесь придумать какой-то невозможный гибрид из двух разных версий питона в одном дистрибутиве, с пересборкой всех модулей и скриптов под оба питона сразу. Я не понимаю зачем это нужно. Мало того, я не понимаю, если вам это нужно - то почему вы списали со счетов python21 и python1.52? Я могу привести примеры кода и примеры пакетов, для которых такое списание может оказатся преждевременным (некоторые продукты для того же Zope). Но - мы же их портируем... > Отсюда с необходимостью следует, что, если мы говорим о том, что, > с одной стороны, HEAD ведется на последнем (в данный момент, 2.3) > питоне, а, с другой стороны, поддержку предыдущих версий _вашего_ > продукта необходимо осуществлять в старом окружении, то мы с > необходимостью приходим к двум питонам и двум версиям каждого из модулей > на машине, по крайней мере, человека, который одновременно осуществляет > и разработку, и поддержку. Возможна, конечно, установка второй версии > питона куда-нибудь в chroot/vmware и т.п. но это требует по сути, > полноценного виртуального сервера. Я уже объяснил - для поддежки старых версий существует AltLinuxMaster22 и апдейты к нему. Везде на хостинге у меня стоит ALM22, а в одном сильно коммерческом месте - ALM20, и я _не_собираюсь_ его апдейтить до сизифа по неоднократно описанным вами причинам. Там стоит софт, на портирование которого нет денег. Но сизиф - для разработчиков. Я думаю, что это общее мнение. Кстати, для поддержки мастера я, по рекомендации старших товарищей, специально держу установленный мастер и считаю что это единственно верный путь. Работаю с ним иногда через chroot, иногда - перегружаюсь. Это всего около 150 метров. > > По поводу py, pyc, pyo - я сейчас работаю над тем, что бы начится > > безболезненно разбивать модули на три составляющих: > > Замечательно. То, как это делает, н-р, emacs, можно взять за основу? Напомните, что делает emacs? > И, кстати, я испугался заранее фразы "решает еще ряд проблем". Что там > еще не так? В основном это так скажем, условно, "словари". Код очень большого объема, частично автоматически генерированный. Если мы ставим py+pyc+pyo - получается некислый объем на диске. Хотя из них, при соблюдении определенных предостарожностей, любые два можно изъять. Сейчас в rPAS (это собствено пакет на котором я ставлю опыты) спокойно работает при установке для таких продуктов только файлов *pyc, когда цели отладки требуют - всегда можно доставить соотв. пакет -src. В принципе, удобно, но в rPAS и так 15 пакетов, а с таким делением получается 35, что немного тяжело для поддержки. C Zope ситуация примерно та же. Вот сбсно над проблемами автоматизации я в свободное время размышляю. Кстати, я не прочь поразмышлять вместе, тем более, что насколько я понял, вы хороший специалист по макросам rpm и т.п. -- WthBstRgrds -- Андрей Орлов -- --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org --- ----------------------------------------