[devel] Сборка пакетов , содержащих .py

Сб Янв 17 00:02:34 MSK 2004

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 ---
----------------------------------------