From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 12 Feb 2004 16:03:01 +0600 From: Alexey Morozov To: ALT Devel discussion list Subject: Re: [devel] Python Modules Policy: Message-ID: <20040212100301.GG16285@pyro.hopawar.private.net> 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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qp4W5+cUSnZs0RIF" Content-Disposition: inline In-Reply-To: <402B3987.80901@l14.ru> User-Agent: Mutt/1.4i 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 10:03:05 -0000 Archived-At: List-Archive: List-Post: --qp4W5+cUSnZs0RIF Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Thu, Feb 12, 2004 at 11:29:59AM +0300, Алексей Любимов wrote: > >Нет. Их можно будет собирать "неодновременно", т.е. в два прохода. > >Может быть, даже автоматом. > > > А, так это в том смысле, что из одного спека за один проход собирать > пакеты для всех питонов трудоемко? > Это как раз само собой разумеется. > > Раз так, то на зоп в сизифе и все, что посложнее "hello world" можно (и > нужно) не забивать :) См. письмо про RFC. Андрей Орлов в джаббере высказал мнение, что, возможно, стоит пойти по другому пути, с доводкой до ума libAltDist. Возможно, это тоже путь. Более подробно он выскажется сам. Сейчас, я так понимаю, нужно выслушать мнение тех, кто реально будет эти самые модуля собирать (и использовать). > >ldv@ уже предложил решение, которое, вроде бы, не хуже по последствиям, > >но автоматизируется. Прокомментируйте его, пожалуйста. > Менять макросы rpmbuild? > По моему это источник еще одной головной боли. > Опять будет куча unmets, как это происходит при любом чихе сейчас с > перлом и прочими. См. моё решение. F*cking magic, но таки "работает для меня". Причем, если нужно, добавки происходят относительно безболезненно, как _мне_ _кажется_ в _настоящее время_ > Но самое главное, будет непрозрачное повдение rpm при сборке пакета. > Проблема с с зависимостями питона не так серьезна, чтобы рубить с плеча. > По моему все очень просто - поставил Requires: python = % и > получил нужную зависимость. Все автоматом происходит. Аллилуйя! :-) > А не поставил - получил более свободный и универсальный вариант. Всем > хорошо и никому плохо. Но для модулей такая зависимость реально нужна. > >>>Предлагается подумать над следующими двумя полиси: > >>>6. Программы на python, не зависящие от конкретной версии питона > >>>(epydoc, python-doc-tools), собираются _без_ байткода и, > >>>соответственно, без привязки к точной версии питона, используется > >>>#!/usr/bin/env python ... > >>> > >>> > >>А где же они лежать будут? по логике все равно в > >>python?.?/site-packages/ > >> > >> > >Нет. Питоньи скрипты (н-р, python-doc-tools) лежат не там. > >epydoc тоже лежит не там, вроде бы. Если нужно подумать над > >"версионно-независимом" каталоге для питона, его можно организовать, > >насколько я понимаю. > Ну так это же просто программы на питоне. > Однако все равно любая такая прога сложнее трех строк зависит от > импортируемых модулей из python?.?/site-packages/. Да, конечно. Но они как правило говорят просто import smth а уж откуда этот smth потянется - забота того питона, при помощи которого эта прога выполняется. Сменится питон, сменится и место. Но это никак не заденет саму прогу (вопросы совместимости разных версий _языка_ оставим в стороне) > репорте gdesklets22, а не gdesklets? Да и класть только > некомпилированные модули в пакет, это фактически ухудшить качество > пакета. Скомпилировать его юзер уже не сможет и ему будет выгоднее > просто скопировать содержимое к себе в хоум и запускать оттуда. На этот > слакварный вариант целимся? Нет, Алексей, я, видимо, плохо объяснил свою точку зрения. Смотрите, как это вижу себе я: * имеется Twisted (благо, он действительно имеется, собран и подходит для примера) * при сборке образуются следующие модули: * python-Twisted - сборище _модулей_ из Twisted (вероятно, я распилю этот пакет на Twisted, Twisted-web, Twisted-gtk итп) * python-Twisted-utils - вещи, которые, грубо говоря, идут в /usr/bin/ и от конкретной версии питон не зависят * python-Twisted-doc и всё остальное прочее барахло, которое потребно лишь девелоперам > >Без разможения пакетов - плохо, по-моему. Я сейчас периодически сам > >заглядываю в твистедовые потроха, чтобы понять, что же имелось ввиду в > >доке. > я имею в виду не молчаливое удаление *.py как это сделали с *.la, а > некий инструмент, селектирующий систему после (и в процессе) установки. Ну, можно, конечно, оформить это как %def_without python_source, но, гхм... В общем, думать надо. > А под размножением пакетов я имею в виду следующее: > что у нас сегодня есть из _одного_ пакета/дистрибутива Zope > > Zope-DateTime - Date and time representation ... > Zope-reStructuredText - reStructuredText - enhanced automatic text markup > > То есть один дистрибутив расщепился на 15 пакетов, что уже много. В общем, пилить его надо. Не знаю, какова ситуация именно с Zope, но по зависимостям полный Twisted, если его паковать правильно, тянет, н-р, pygtk, который тянет GTK+/Glade, а что начинается дальше, в общем, рассказывать не надо, да? :-) И это несмотря на то, что я, в общем, захотел безобидной вещи, простенький серверок поверх http запустить :-) "Абидна, да-а?! Ничего нэ сдэлал, да-а?!" Так что, бить на подпакеты нужно. Другое дело, что сорцы вполне могут ехать в одном большом пакете, который "требует всего". Девелоперу можно и иксу поставить, гигабайты нынче дешевы. Кстати, насчет .pyc vs .pyo. В .pyc есть какой-нибудь смысл при наличии .pyo (кроме отдельно оговоренных единичных случаев)? > Замечу, что зоп, это здорово, но еще далеко не все. Угу. > > Вот, что дополнительно используется только на www.linux-os.ru (ничего > такого специфичного) > > ArchExample ... Супер. > а какой смысл в разделении? не проще ли собрать два пакета вместо > четырех, полностью их скомпилировать и в дальнейшем сопровождать? Очень просто. Когда я ставлю/запускаю /это/ я говорю twisted -ny server_start.py (или вообще .tap) При этом версия питона "по умолчанию" мне, в общем, по барабану (ну, при условии, что у меня код написан так, что его реально можно таскать. Если таскать нельзя, то в том месте, которое таскать нельзя стоит: "нужен именно pythonX.Y!" и старт обламывается). При этом мне не нужно ни альтернатив (которые, вообще-то, не самостоятельные в данном случае, а slave'ы на python), ничего специального. Выбор версии питона происходит в момент пробегания по /usr/bin/python -> ... -> /usr/bin/pythonX.Y > >У Андрея были практические соображения, почему в боевую версию НЕ надо > >пихать сорцы. С другой стороны, мой небольшой практический опыт > >показывает, что сорцы _иногда_ нужны. > мой опыт говорит, что сырцы нужны всегда или почти всегда. > вот сейчас пытаюсь завести науменовскую crm 2.3 без сырцов и ни хрена не > получается. > версия 2.2 с сырцами завелась практически сразу, потому как из них было > видно, что конкретно не устраивает программу. Удачи :-)) > >Это никак не упихивается в рамки distutils? > /usr/lib/python2.3/site-packages/libaltdist.py ? > не похоже. > Эта штука должна по идее сопровождать установленную систему все время > его существования (как апт или control) и даже иметь страничку в > конфигураторе (которого нет). > Вобщем пока все слишком непонятно, чтобы обсуждать рамки. Ну, когда-то надо начинать. --qp4W5+cUSnZs0RIF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAK09VX5DZdJn19V0RAsi9AJ9c/1wwsBiIs4mYvJ+OJ+VUmXClxwCdFJmT kNIXGJ4azuxSRnvcehSw5Ik= =d0+x -----END PGP SIGNATURE----- --qp4W5+cUSnZs0RIF--