On Fri, Jan 16, 2004 at 06:10:40PM +0300, Andrey Orlov wrote: > On Friday 2004 January 16 13:50, Alexey Morozov wrote: > > On Fri, Jan 16, 2004 at 10:12:43AM +0300, Andrey Orlov wrote: > > > > Особенно автороство того, кто и что вам говорит? На этот вопрос > > > отвечали, в разное время, два человека - я & Максим, и ответ был > совсем > > > не такой. > > Вопрос был другой :-)). И отвечали на него не Вы :-) > Тогда почему вы приписали этот ответ мне? Вы сказали - один из > занимающихся сборкой python. Если верить changelog - Максим сборкой > python не занимался, последние сборки python - мои. Мой же ответ был > другой, и так как мне влом искать его в pipermail, то я его повторяю > специально для вас еще раз: Андрей, я написал: кто-то из команды. Поскольку я не помнил точно, и искать, как Вы говорите, влом, то и указание получилось достаточно расплывчатым. Чес-слово не хотел Вас задеть, не надо так реагировать. > "Исходный код программ на питоне в общем случае не переносим при смене > 2.1 -> 2.2 -> 2.3. Это для меня _очень_ большая проблема, решением > которой на почве сервера приложений Zope я занимаюсь уже два года, и > об этой проблеме в свое время было написано не мало писем > русскоязычной питоновской рассылке." Все понятно, я понял про исходный код, и хорошо, что в команде есть человек, который плотно сталкивался с проблемами переносимости. У меня такие проблемы, видимо, возникнут, и здорово будет обратиться к Вам за поддержкой. Но, повторюсь, в данном конкретном случае, вопрос касался другой темы, а именно, ненужной привязки некоторых достаточно простых скриптов к версии питон в момент сборки пакета. > Только что (см. патчи к Z262) пришлость устранять из Zope > несовместимости с новой версией python. Если вы загляните на сайт > zope.org, то увидите, что половина changes в Zope263 посвящены именно > переносу его на python23. Ну, если это _необходимость_, а не желание следовать веяниям времени, то это грустно, на самом деле. > > > /usr/lib/python2.2 > > /usr/share/python2.2 > > Кто прав, Максим или доки на питон, я не знаю, но это, в общем, в > > контексте вопроса, обсуждаемого в _этом_ треде, и не важно. > Скомпиленный питоновский модуль нельзя разместить с другим путем. Так Но можно же задать при сборке собственно питона другое расположение библиотечных путей, правда? > как после этого он начинает немножко неправильно работать, (кажется, > в частности, выдавать неверную диагностику). Установлено это было еще > до моего прихода в команду, и кажется именно этим обусловлена > __двойная__ байт-компиляция всего питоновского кода. Подробнее об > этом может рассказать LDV если я правильно понимаю. Ok, спросим LDV. > Я еще раз вам говорю: такие зависимости есть. Самые заметные из них - > начиная с версии 23 питоновская программа не должна содержать > символов из второй половины кодовой таблицы или должна содержать > специальный заголовок с указанием кодировке. Без этого будет > выводится warning, вывод которого, в некоторых случаях, приводит к > нарушению работы скриптов и их окружения. Другие изменения, опять же > самыае заметные: None стало ключевым словом (половина Access* в Zope > отвалилась), модуль rotor был задеприкейчен - что опять же привело > к некислой правке того же Zope. Андрей, я понимаю Вашу озабоченность проблемами сборки Zope. Но у меня сейчас немного другие проблемы, не затрагивающие впрямую Zope. И я НЕ претендую на универсальность моего решения. > > Итого, сухой остаток: > > > > Долой /usr/lib/rpm/brp-bytecompile_python! > > Даешь /usr/lib/rpm/python.{req,prov}! > Сухой остаток: я бы попросил ничего не менять, не разобравшись. Именно это я и пытаюсь сделать. > Прекомпиляцию модулей лучше пока оставить, тем более что именно в > контексте етого треда, ее изъятие _вашей_ проблемы не решит, из-за > непериносимости _исходного_ кода на языке питон в _общем_ случае. Мне, все же кажется, что _мою_ проблему это решит замечательно, поскольку те конкретные скрипты, о которых я веду речь, нормально работают на всех последних версиях питона. Что же касается всех остальных python-скриптов в мире, то, как мне кажется, с принудительной байт-компиляцией мы получаем _две_ проблемы вместо _одной_: во-первых, возможны нюансы, касающиеся переносимости собственно кода (но на это хоть диагностика будет внятная), во-вторых, возможны проблемы с переносимостью байткода как такового (и я совершенно не уверен в том, как поведет себя питон, увидев несовместимый байт-код). В данном треде я совсем НЕ РАССМАТРИВАЛ первую проблему, целиком занимаясь исключительно второй. > Если вы считаете что _ваш_ пакет не должен содержать *pyc & *pyo - вы > можете не _включать_ их в секцию files _вашего_ spec'а. А все Могу. Но, во-первых, для модулей, все же, _хочется_ включать байткод, причем, откомпилированный именно тем питоном, который потом будет этот модуль использовать (сейчас это, по факту НЕ ТАК, если вместо %__python используется, скажем, python-2.3). А во-вторых, мне, все же, больше нравится оперировать списком файлов, сформированных на этапе setup.py install а не произвольными каталогами (хотя, возможно, это и относится к области [неверных] личных предпочтений). > глобальные изменения порядка комплиции стоит согласовывать со всеми. Именно это я и делаю на протяжении последних нескольких писем. > Пока что _лично_я_ против таких изменений, и я хотя я согласен что > ситуацию с pyc & pyo надо менять - я против изъятия прекомпиляции как > таковой, так как наличие байткомпиляции является существенным > преимуществом питона перед, скажем, перлом. Я не пытаюсь изъять байткомпиляцию. См. мои предыдущие письма в этом треде относительно использования возможностей и данных distutils, а не компиляции всего, что хоть отдаленно напоминает python. > > Давайте жить дружно! > Давайте, только прислушивайтесь к чужому мнению? Как мне кажется, и так уже прислушиваюсь. > На сегодняшний день оно такое: > > 1. Перенос байт-кода из одной версии в другую не допустим; Ура. Здесь мы с Вами едины во мнении. > 2. Перенос исходного кода из одной версии в другую может приводить к > ошибкам, что отменяет возможность решения проблемы двух питонов за > счет отказа от прекомпиленного кода; Нет. Это решение _другой_ проблемы. См. выше. > 3. Сама проблема двух питонов является надуманной, так как никакой > необходимости держать два питона на одной машине я не знаю; Андрей, выше Вы пишете о том, что при переезде с python-2.2 на python-2.3 отвалилась большая часть Zope, и понадобилось ненулевое время на исправление ситуации. В другом письме Вы (я все же надеюсь, что это были Вы) пишете, что разработчики в своей деятельности должны использовать самые модные наработки. Отсюда с необходимостью следует, что, если мы говорим о том, что, с одной стороны, HEAD ведется на последнем (в данный момент, 2.3) питоне, а, с другой стороны, поддержку предыдущих версий _вашего_ продукта необходимо осуществлять в старом окружении, то мы с необходимостью приходим к двум питонам и двум версиям каждого из модулей на машине, по крайней мере, человека, который одновременно осуществляет и разработку, и поддержку. Возможна, конечно, установка второй версии питона куда-нибудь в chroot/vmware и т.п. но это требует по сути, полноценного виртуального сервера. > 4. Отказ от прекомпиляции является большой ошибкой, т.к. > прекомиплияция являетс существенным преимуществом языка питон. С этим никто не спорит. > По поводу py, pyc, pyo - я сейчас работаю над тем, что бы начится > безболезненно разбивать модули на три составляющих: > > module-src, module, module-opt - каждый из которых содержит только > один тип прекомпиленных модулей. Никаких проблем здесь не возникает > (так ставится один мой проект), но пока что это не автоматизировано, > чем собственно я и занимаюсь. На самом деле, я не вижу проблем в том, > что бы при установке модулей, в норме, не ставить исходников этих > модулей, что существенно экономит место и решает еще ряд проблем. Замечательно. То, как это делает, н-р, emacs, можно взять за основу? И, кстати, я испугался заранее фразы "решает еще ряд проблем". Что там еще не так? > Я это к тому, что бы было известно в какую сторону думаю, скажем, я. Ok, буду иметь ввиду.