[devel] Q: Python packaging howto

[devel] Q: Python packaging howto

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

Привет.

Хотелось бы узнать, желательно в виде howto или примера spec'а, как
сложился/складывается официально одобренный способ сборки модулей
для python. На меня повесили сборку PyXML для python 2.3, хотелось
бы это сделать сразу правильно.

Мои беглые мысли по поводу отдельных идей, высказанных в дискуссии
(кстати, с архивами в http://www.altlinux.ru/pipermail/devel/
какая-то беда: части сообщений я там не вижу). Отбрасывать .pyc
нежелательно, поскольку это то, что интерпретатор использует
по умолчанию без ключа оптимизации. Я не уверен, скажем, что отладка
работает на .pyo
Вообще вся затея обеспечить постепенную миграцию может принести
больше проблем, чем разовая смена всех модулей в день Д с
предварительной подготовкой, возложенной на packager'ов.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
Show your affection, which will probably meet with pleasant response.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: Python packaging howto

[Klimchev Konstantin]

On Fri, 20 Feb 2004 15:00:41 +0300
Mikhail Zabaluev <mhz@altlinux.org> wrote:

> Хотелось бы узнать, желательно в виде howto или примера spec'а, как
> сложился/складывается официально одобренный способ сборки модулей
> для python. 

Присоединяюсь. Хотелось бы расставить все точки.

-- 
Best Regards, Konstantin Klimchev 
(mailto:koka@atvc.ru    jabber:koka@jabber.ru)
ATK-Internet ISP, Arkhangelsk, Russia

Re: [devel] Q: Python packaging howto

[Andrey Orlov]

В сообщении от Пятница 20 Февраль 2004 15:00 Mikhail Zabaluev написал:
> Хотелось бы узнать, желательно в виде howto или примера spec'а, как
> сложился/складывается официально одобренный способ сборки модулей
> для python. На меня повесили сборку PyXML для python 2.3, хотелось
> бы это сделать сразу правильно.

Он еще официально не одобрен. Я жду ответов от некоторых людей. Тем не
менее, HOWTO, завтра попробую написать (в будни совершенно нереально, увы).

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

Re: [devel] Q: Python packaging howto

[Alexey Morozov]

[-- Attachment #1.1: Type: text/plain, Size: 3887 bytes --]

On Fri, Feb 20, 2004 at 03:00:41PM +0300, Mikhail Zabaluev wrote:
> Хотелось бы узнать, желательно в виде howto или примера spec'а, как
> сложился/складывается официально одобренный способ сборки модулей
> для python. На меня повесили сборку PyXML для python 2.3, хотелось
> бы это сделать сразу правильно.
В аттачменте файл python, который, по-хорошему, идет в python-common
и пример спек файла. Собирать при помощи

rpmbuild -ba pyserial.spec

На выходе будет python-pyserial-*.rpm, причем, бинарные rpm привязаны к
текущей (вероятно, 2.3) версии python. Если нужна сборка под какой-либо
конкретный питон, то

rpmbuild -ba pyserial.spec --with pythonXY

на выходе будут получаться

pythonXY-pyserial...rpm

в данный момент, в качестве XY может использоваться 22, 23 и (задел на
будущее) 24. К сожалению, я не придумал, как можно сделать это место
полностью универсальным.

Зависимости на пакеты с другими модулями python надо прописывать как

Requires: python%__python_package_version-<anotherModule>

Могу оформить все это дело в виде отдельного макроса. Предложения по
наименованию принимаются.

Да, попробуйте все это погонять в разных установочных средах, возможно,
в макросах есть ошибки и/или недочеты.

> Мои беглые мысли по поводу отдельных идей, высказанных в дискуссии
> (кстати, с архивами в http://www.altlinux.ru/pipermail/devel/
> какая-то беда: части сообщений я там не вижу). Отбрасывать .pyc
> нежелательно, поскольку это то, что интерпретатор использует
> по умолчанию без ключа оптимизации. Я не уверен, скажем, что отладка
> работает на .pyo
Данные макросы никак не затрагивают эту область. То есть, метод
сборки и упаковки определяется исключительно пэкеджером. Единственное
условие - делать в конце %install unset RPM_PYTHON, чтобы исключить
скорее всего нежелательную (повторную) байт-компиляцию. Хотя, конечно,
сейчас этот самый RPM_PYTHON, по-хорошему, будет указывать именно на ту
версию питона, для которой собирается пакет (даже если идет сборка по
умолчанию)

У меня есть идея оформить стандартные действия при инсталляции макросами,
аналогичными %perl_vendor_build/%perl_vendor_install, которые бы покрывали
основные нужды сборщиков (при использовании distutils). Вероятно, сегодня
ближе к вечеру это будет сделано. Скорее всего, по умолчанию будут
паковаться только .pyo, но, надеюсь :-), будет возможность, во-первых,
собрать [отдельный] пакет с .py, а, во-вторых, переключиться на
использование .pyc.

> Вообще вся затея обеспечить постепенную миграцию может принести
> больше проблем, чем разовая смена всех модулей в день Д с
> предварительной подготовкой, возложенной на packager'ов.
Я тут уже высказывал сомнения в практической реальности такого "Часа Ч".
Вкратце: не все питоньи модули можно пересобрать в тот же момент, когда
появляется новая версия питона. Пример - Zope, который его создателям и
Андрею понадобилось патчить для обеспечения функционирования под
python2.3. Как следствие, "Час Ч" растягивается по времени месяца на
полтора-два. А вот, например, мне ждать Зоупа нет никакого смысла,
поскольку я его не использую, а Твистед, кажется, едет на 2.3 вполне прилично.
Ну и так далее. Конечно, в "дистрибутив" крайне желательно запихивать
только один питон с полным набором модулей к нему.

Дополнительные замечания по поводу сборки:

в данной схеме есть один, как мне кажется, недочет. Если некто
пересобирает модуль вида pythonXY-pyModule-K.L.M-altN.src.rpm, не
указывая --with pythonXY, то на выходе он получает модуль, привязанный к
ТЕКУЩЕЙ версии питона, а не к версии X.Y. Имена и зависимости пакетов
изменяются соответственно (то есть, будет
python-pyModule-K.L.M-altN.i586.rpm, зависящий от python, запускаемого
как /usr/bin/python).

В принципе, я, похоже, уже знаю, как обойти эту проблему (если это проблема),
правда, блин, хак будет тот еще (хоть и не требующий изменения ни в спеке,
ни в rpm). Такая возможность интересна?


[-- Attachment #1.2: pyserial.spec --]
[-- Type: text/plain, Size: 2943 bytes --]

# -*- coding: utf-8 -*-
%define	version	2.0
%define release alt2

%setup_python_module pyserial

Summary: Serial port access for python
Summary(ru_RU.UTF-8): Доступ к последовательному порту из python
Name: %packagename
Version: %version
Release: %release
Source: %modulename-%version.zip
License: Python
Group: Development/Python
Prefix: %_prefix
Url: http://pyserial.sf.net


# Automatically added by buildreq on Wed Jan 14 2004
BuildRequires: unzip

%description
This module capsulates the access for the serial port. It provides
backends for standard Python running on Windows, Linux, BSD (possibly
any POSIX compilant system) and Jython. The module automaticaly
selects the appropriate backend.

This module is built for python %__python_version

%description -l ru_RU.UTF-8
С помощью этого модуля можно работать с последовательным портом в
стандартном Python, запущенном на Windows, Linux, BSD (возможно, любой
POSIX-совместимой системе) или Jython. Модуль автоматически выбирает
подходящий для данной системы механизм доступа.

Этот модуль собран для Python версии %__python_version

%package -n python-%modulename-doc
Summary: %modulename documentation and example programs
Summary(ru_RU.UTF-8): Документация по API и примеры программ для %modulename
Group: Development/Python
Prefix: %_prefix
Requires: python-%modulename = %version
%description -n  python-%modulename-doc
%modulename provides portable way to access serial ports in various
systems. Install python-%modulename-doc if you need API documentation
and examples for this module

%description -n  python-%modulename-doc -l ru_RU.UTF-8
%modulename предоставляет унифицированный доступ к последовательному
порту в разных системах. Установите python-%modulename-doc, если Вам
требуется документация по API и примеры программирования с
использованием данного модуля.

%prep

%setup -q -n %modulename-%version

%build
mkdir -p buildroot

# Unfortunately build and install steps should be done at once
# because otherwise .pyo files won't get into INSTALLED_FILES
# record

CFLAGS="%optflags" %__python setup.py \
	install --optimize=2 \
		--root=`pwd`/buildroot \
		--record=INSTALLED_FILES
%install

cp -pr buildroot %buildroot/

unset RPM_PYTHON

%files -f INSTALLED_FILES
%doc changes.txt readme.txt

%files -n python-%modulename-doc
%doc examples


%changelog
* Wed Jan 14 2004 Alexey Morozov <morozov@altlinux.org> 2.0-alt1
- Initial build for ALT Linux

[-- Attachment #1.3: python --]
[-- Type: text/plain, Size: 1115 bytes --]

%check_python_version_internal() \
%{expand: %{expand:%%{?_with_python%{2}:%%{?__python_package_version:%%%%{error:Only one python version can be selected at a time}}}}} \
%(echo %{expand:%%{?_with_python%{2}:%%{?__python_package_version:BuildConflicts: python = %{1}}}}) \
%(echo %{expand:%%{?_with_python%{2}:BuildPreReq: python = %{1}}}) \
%{expand: %{expand:%%{?_with_python%{2}:%%%%global __python %(which python%1 2>/dev/null || echo /bin/false)}}} \
%{expand: %{expand:%%{?_with_python%{2}:%%{!?__python_package_version:%%%%global __python_package_version %2}}}}

%check_python_version() \
%{expand: %%check_python_version_internal %{1} %(echo %1 | sed -e 's/\\.//g')}

%setup_python_module()	\
%{expand: %%global modulename %{1}} \
%(echo Provides: python-%{1} = %version-%release) \
%check_python_version 2.2 \
%check_python_version 2.3 \
%check_python_version 2.4 \
%{expand: %{expand: %%{!?__python_package_version:%%%%global __python_package_version %%%%nil}}} \
%{expand: %%global packagename python%%{__python_package_version}-%%{modulename}} \
%(echo %{expand:Requires: python = %%__python_version})

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: Python packaging howto

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 5513 bytes --]

Hello Alexey,

On Sat, Feb 21, 2004 at 05:37:26PM +0600, Alexey Morozov wrote:
>
> В аттачменте файл python, который, по-хорошему, идет в python-common
> и пример спек файла. Собирать при помощи
> 
> rpmbuild -ba pyserial.spec
> 
> На выходе будет python-pyserial-*.rpm, причем, бинарные rpm привязаны к
> текущей (вероятно, 2.3) версии python. Если нужна сборка под какой-либо
> конкретный питон, то
> 
> rpmbuild -ba pyserial.spec --with pythonXY
> 
> на выходе будут получаться
> 
> pythonXY-pyserial...rpm

Мне не нравится идея, что основное имя (то, которое принимает
.src.rpm) зависит от ключей сборки. На самом-то деле исходный
пакет от этого не зависит.

Может быть, лучше для Name: оставить имя модуля, без всяких python*-,
а для объявления бинарного пакета предусмотреть макросы? Впрочем,
это будет не очень удобно, если макрос для объявления бинарного пакета
не будет автоматически копировать %description основного пакета.
Я не знаю, можно ли это сделать в rpm.

Есть ещё такая радикальная идея: бинарный пакет может именоваться и
по-человечески, именем tarball'а, но предоставлять также имя,
привязанное к версии ABI python. При этом могут использоваться
скобочные схемы, например:
python-abi(%modulename) = %__python_version

После этого корректное прописывание зависимостей между пакетами
модулей останется предметом policy.

> в данный момент, в качестве XY может использоваться 22, 23 и (задел на
> будущее) 24. К сожалению, я не придумал, как можно сделать это место
> полностью универсальным.
> 
> Зависимости на пакеты с другими модулями python надо прописывать как
> 
> Requires: python%__python_package_version-<anotherModule>
> 
> Могу оформить все это дело в виде отдельного макроса. Предложения по
> наименованию принимаются.

Помимо изложенного выше предложения, есть такой вариант:

%{python_versioned_name anotherModule}

а также
%__python_packagename python%__python_package_version

> Данные макросы никак не затрагивают эту область. То есть, метод
> сборки и упаковки определяется исключительно пэкеджером. Единственное
> условие - делать в конце %install unset RPM_PYTHON, чтобы исключить
> скорее всего нежелательную (повторную) байт-компиляцию. Хотя, конечно,
> сейчас этот самый RPM_PYTHON, по-хорошему, будет указывать именно на ту
> версию питона, для которой собирается пакет (даже если идет сборка по
> умолчанию)

Насколько я понимаю, компиляция после %install необходима только для
тех скриптов, которые не используют схему установки из distutils
с опцией --root. Если так, то да, лучше её отключить.

По идее, нужно добиться, чтобы RPM_PYTHON была установлена правильно
во всех случаях.
Как насчёт %set_python_version по примеру autoconf/automake/libtool?
Тогда /usr/bin/python из python-common запустит требуемую версию
или контролируемый альтернативами /usr/bin/python-default.

Этот же трюк позволит избавиться от --with-pythonXY и таинственного
макроса setup_python_module: тем, кто захочет зафиксировать версию
python в своей сборке, достаточно будет вставить
%set_python_version X.Y в spec.

> У меня есть идея оформить стандартные действия при инсталляции макросами,
> аналогичными %perl_vendor_build/%perl_vendor_install, которые бы покрывали
> основные нужды сборщиков (при использовании distutils). Вероятно, сегодня
> ближе к вечеру это будет сделано. Скорее всего, по умолчанию будут
> паковаться только .pyo, но, надеюсь :-), будет возможность, во-первых,
> собрать [отдельный] пакет с .py, а, во-вторых, переключиться на
> использование .pyc.

Достаточно определить макрос для уровня оптимизации, %python_optlevel,
и использовать его в опции --optimize (с разумным fallback'ом).

> Дополнительные замечания по поводу сборки:
> 
> в данной схеме есть один, как мне кажется, недочет. Если некто
> пересобирает модуль вида pythonXY-pyModule-K.L.M-altN.src.rpm, не
> указывая --with pythonXY, то на выходе он получает модуль, привязанный к
> ТЕКУЩЕЙ версии питона, а не к версии X.Y. Имена и зависимости пакетов
> изменяются соответственно (то есть, будет
> python-pyModule-K.L.M-altN.i586.rpm, зависящий от python, запускаемого
> как /usr/bin/python).

Мне кажется, бинарный пакет с модулем должен всегда быть привязан
к конкретной версии python ABI, коль скоро он содержит байт-код
под этот ABI. Точно так же, нет смысла в общем имени каталога
/usr/lib/python


> %build
> mkdir -p buildroot
> 
> # Unfortunately build and install steps should be done at once
> # because otherwise .pyo files won't get into INSTALLED_FILES
> # record
> 
> CFLAGS="%optflags" %__python setup.py \
> 	install --optimize=2 \
> 		--root=`pwd`/buildroot \
> 		--record=INSTALLED_FILES
> %install
> 
> cp -pr buildroot %buildroot/


Не увидел проблем при использовании обычной схемы:


%build
CFLAGS="$RPM_OPT_FLAGS" python setup.py build

%install
python setup.py install \
       --optimize=%python_optlevel \
       --root=$RPM_BUILD_ROOT \
       --record=INSTALLED_FILES


.pyo и .pyc исправно попадают в INSTALLED_FILES.
Проверял, правда, только на 2.3.


P.S. Залил в Sisyphus python-doc версии 2.3.3. Было бы неплохо, если
бы maintainer Python своевременно обновлял также и этот пакет.
Там можно прочитать о хорошем способе генерации начального .spec
для модуля:
python setup.py bdist_rpm --spec-only
Я думаю, об этом стоит написать в HOWTO.
А может быть, даже подправить шаблон для .spec'а для того, чтобы
он получался сразу готовым к употреблению.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
Daemon escaped from pentagram

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: Python packaging howto

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]

On Sat, Feb 21, 2004 at 09:25:33PM +0300, Mikhail Zabaluev wrote:
> On Sat, Feb 21, 2004 at 05:37:26PM +0600, Alexey Morozov wrote:
> >
> > В аттачменте файл python, который, по-хорошему, идет в python-common
> > и пример спек файла. Собирать при помощи
> > 
> > rpmbuild -ba pyserial.spec
> > 
> > На выходе будет python-pyserial-*.rpm, причем, бинарные rpm привязаны к
> > текущей (вероятно, 2.3) версии python. Если нужна сборка под какой-либо
> > конкретный питон, то
> > 
> > rpmbuild -ba pyserial.spec --with pythonXY
> > 
> > на выходе будут получаться
> > 
> > pythonXY-pyserial...rpm
> 
> Мне не нравится идея, что основное имя (то, которое принимает
> .src.rpm) зависит от ключей сборки. На самом-то деле исходный
> пакет от этого не зависит.

Я тоже считаю, что это не очень удачная идея.

[...]
> > Зависимости на пакеты с другими модулями python надо прописывать как
> > 
> > Requires: python%__python_package_version-<anotherModule>
> > 
> > Могу оформить все это дело в виде отдельного макроса. Предложения по
> > наименованию принимаются.
> 
> Помимо изложенного выше предложения, есть такой вариант:
> 
> %{python_versioned_name anotherModule}
> 
> а также
> %__python_packagename python%__python_package_version

См. тж. /etc/rpm/macros.d/pam, может, что-нибудь красивее придумается.

[...]
> Как насчёт %set_python_version по примеру autoconf/automake/libtool?
> Тогда /usr/bin/python из python-common запустит требуемую версию
> или контролируемый альтернативами /usr/bin/python-default.
> 
> Этот же трюк позволит избавиться от --with-pythonXY и таинственного
> макроса setup_python_module: тем, кто захочет зафиксировать версию
> python в своей сборке, достаточно будет вставить
> %set_python_version X.Y в spec.

Логично.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: Python packaging howto

[Alexey Morozov]

[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]

On Sat, Feb 21, 2004 at 10:14:44PM +0300, Dmitry V. Levin wrote:
> > > pythonXY-pyserial...rpm
> > Мне не нравится идея, что основное имя (то, которое принимает
> > .src.rpm) зависит от ключей сборки. На самом-то деле исходный
> > пакет от этого не зависит.
> Я тоже считаю, что это не очень удачная идея.
Ну, я уже объяснял, что в поставленных условиях это до сих пор представляется
мне единственным реализуемым решением. Если будет возможность автоматического
создания бинарного пакета с именем, отличным от имени сорцового пакета, тогда
да, можно будет отказаться от pythonXY-pyModule-...src.rpm. Но как
_копировать_ все эти %description'ы и прочие Summary текущей
функциональностью rpm, я не знаю. Есть вариант, конечно, отказаться от
использования средств rpm, уйдя целиком на средства distutils/libAltDist.
Спек, даже сложный, можно будет сгенерить [один раз], а потом им пользоваться.
Но это вовлекает в решение задачи не готовые на данный момент средства.

> > %__python_packagename python%__python_package_version
> 
> См. тж. /etc/rpm/macros.d/pam, может, что-нибудь красивее придумается.
> 
> > Этот же трюк позволит избавиться от --with-pythonXY и таинственного
> > макроса setup_python_module: тем, кто захочет зафиксировать версию
> > python в своей сборке, достаточно будет вставить
> > %set_python_version X.Y в spec.
> Логично.
Нет. Не решает изначальную задачу. Собственно, весь сыр-бор начался, когда
стало понятно, что с одновременным существованием в _девелоперском_
репозитории двух версий питон надо что-то делать. С одной стороны, надо,
конечно, мигрировать всем на новый питон, с другой, не всегда возможно
собрать и _оттестировать_ под новый питон все имеющиеся в репозитории модули
(пример - Zope и, кажется, PyQt). 

Как следствие, в течение, гхм, двух месяцев в Сизифе не было полностью
работающей питоней подсистемы. Если принять тезис о том, что новая версия
питон выходит раз в год, 20% неработоспособность - это крутовато, по-моему.

Вот и хотелось, с одной стороны, сохранить работоспособный (старый)
питон, и, с другой стороны, открыть дорогу тем, кто уже может мигрировать
на новый питон (скажем, тем, кому не нужен Zope или другие "капризные"
модули).

А что делать с src.rpm'ами - действительно вопрос. Оптимальным ответом на
него было бы: вообще не генерить src.rpm для сборок с --with pythonXY.
Или, как я уже говорил (и это, видимо, технически более осуществимо, как
мне теперь уже /кажется/), привязывать и src.rpm к той специфической версии
питон, которая была указана при сборке.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: Q: Python packaging howto

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 2547 bytes --]

Hello Alexey,

On Sun, Feb 22, 2004 at 06:26:59AM +0600, Alexey Morozov wrote:
>
> > > Этот же трюк позволит избавиться от --with-pythonXY и таинственного
> > > макроса setup_python_module: тем, кто захочет зафиксировать версию
> > > python в своей сборке, достаточно будет вставить
> > > %set_python_version X.Y в spec.
> > Логично.
> Нет. Не решает изначальную задачу. Собственно, весь сыр-бор начался, когда
> стало понятно, что с одновременным существованием в _девелоперском_
> репозитории двух версий питон надо что-то делать. С одной стороны, надо,
> конечно, мигрировать всем на новый питон, с другой, не всегда возможно
> собрать и _оттестировать_ под новый питон все имеющиеся в репозитории модули
> (пример - Zope и, кажется, PyQt). 

Надо сказать, предложенная схема тоже не решает проблемы полностью;
при автоматической пересборке в hasher все равно получается один
из вариантов, два сделать можно только очень исхитрившись.
Да и непонятно, стоит ли. Если кому-то позарез нужна сборка под
"не тот" ABI, пусть пересобирает. В конце концов, незамороженный
Sisyphus не предназначен для удовлетворения потребностей конечных
пользователей.
Сколько сейчас пакетов, которые нужны и под 2.2, и под 2.3?
Может быть, имеет смысл закатать только их, вручную,
из разных src.rpm с отличающимися spec? Точнее, предоставить
legacy-вариант python22-%name, а вариант 2.3 оставить под родным именем?
При условии, что версия ABI для каждого модуля и зависимостей на него
будет прописана жёстко, например, предложенным мной способом, проблем
с зависимостями быть не должно.

> А что делать с src.rpm'ами - действительно вопрос. Оптимальным ответом на
> него было бы: вообще не генерить src.rpm для сборок с --with pythonXY.
> Или, как я уже говорил (и это, видимо, технически более осуществимо, как
> мне теперь уже /кажется/), привязывать и src.rpm к той специфической версии
> питон, которая была указана при сборке.

Загвоздка в том, что .src.rpm не зависит от опций --with и --enable.
Должно быть однозначное соответствие между .spec и .src.rpm,
иначе получаются пакеты с разными именами, не отличающиеся ни
одним байтом.

Итак, я предлагаю не уродовать имена в общем случае, оставив эту
практику для сборок отдельных модулей, по каким-либо причинам нужных
под старый python, когда уже есть тот же модуль под новый. И уж в
этом случае делать и отдельный .src.rpm.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
Go slowly to the entertainments of thy friends, but quickly to their
misfortunes.
		-- Chilo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: Q: Python packaging howto

[Andrey Orlov]

On Sunday 22 February 2004 22:59, Mikhail Zabaluev wrote:
> Да и непонятно, стоит ли. Если кому-то позарез нужна сборка под
> "не тот" ABI, пусть пересобирает. В конце концов, незамороженный
> Sisyphus не предназначен для удовлетворения потребностей конечных
> пользователей.

Наши с Алексеем разговоры пока сводились к тому, что --with pythonXN - это
для домашней пересборки. Т.е. так как вы говорите. Я вообще не понимаю
зачем нужен старый питон ;), впрочем, см. п.1.8 полиси.

> Сколько сейчас пакетов, которые нужны и под 2.2, и под 2.3?
> Может быть, имеет смысл закатать только их, вручную,
> из разных src.rpm с отличающимися spec? Точнее, предоставить
> legacy-вариант python22-%name, а вариант 2.3 оставить под родным именем?

Мы так и делаем. Мало того, даже python23 мы переделали в python. Т.е. для
непосвященного у нас "как будто" один питон.

> Итак, я предлагаю не уродовать имена в общем случае, оставив эту
> практику для сборок отдельных модулей, по каким-либо причинам нужных
> под старый python, когда уже есть тот же модуль под новый. И уж в
> этом случае делать и отдельный .src.rpm.

Мы так и делаем. --with pythonMN - для домашней пересборки, а если "вдруг" потребуется
положить это в сизиф (например, Zope не соберется с python24), то отдельный src.rpm.
Кроме того, см. Полис, п. 1.8. , замечание 3: это все равно в общем (и очень частом) случае
отдельный *.src.rpm.

ЗЫ: Насчет того, чбы убрать префикс вообще - я даже не знаю. Раньше я был за. Сейчас наверно
тоже за. Но, избежать этого, видимо, не удастся (я реалист, большинство не на моей стороне,
какие-то позиции проще сдать), так что я прошу только одного: чбы rpm -qa | grep что-то там,
мог сваливать питон отдельно, модули к нему - отдельно. Пока что я отстаиваю вариант
python-module, если так слишком длинно - то давайте сделаем префикс py- (pyNM), только 
не python- ! Подробнее см. полиси, раздел 2.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

[devel] Re: Q: Python packaging howto

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

Hello Andrey,

On Sun, Feb 22, 2004 at 11:15:10PM +0300, Andrey Orlov wrote:
>
> ЗЫ: Насчет того, чбы убрать префикс вообще - я даже не знаю. Раньше я был за. Сейчас наверно
> тоже за. Но, избежать этого, видимо, не удастся (я реалист, большинство не на моей стороне,
> какие-то позиции проще сдать), так что я прошу только одного: чбы rpm -qa | grep что-то там,
> мог сваливать питон отдельно, модули к нему - отдельно. Пока что я отстаиваю вариант
> python-module, если так слишком длинно - то давайте сделаем префикс py- (pyNM), только 
> не python- ! Подробнее см. полиси, раздел 2.

Логика понятна. Если делать с префиксом, лучше не сокращать.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: Q: Python packaging howto

[Alexey Morozov]

[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]

On Sun, Feb 22, 2004 at 10:59:08PM +0300, Mikhail Zabaluev wrote:
> Надо сказать, предложенная схема тоже не решает проблемы полностью;
> при автоматической пересборке в hasher все равно получается один
> из вариантов, два сделать можно только очень исхитрившись.
Ну, не очень. Я уже знаю как :-). Правда, блин, хак :-)

> Да и непонятно, стоит ли. Если кому-то позарез нужна сборка под
> "не тот" ABI, пусть пересобирает. В конце концов, незамороженный
Именно. Именно для того, чтобы можно было пересобирать под нужную версию
питон скопом, просто через опеределение в .rpmmacros соответствующей
переменной и последующего rpmbuild -ba ... это все и затеивалось.

> Sisyphus не предназначен для удовлетворения потребностей конечных
> пользователей.
:-) Только не говорите им об этом :-)

> Сколько сейчас пакетов, которые нужны и под 2.2, и под 2.3?
Уже не сколько. Но грядет, как говорят, 2.4 ;-)

> Может быть, имеет смысл закатать только их, вручную,
> из разных src.rpm с отличающимися spec? Точнее, предоставить
> legacy-вариант python22-%name, а вариант 2.3 оставить под родным именем?
Ну, "безобразно, зато единообразно". Я, чес-гря, тянул свои идеи, в частности,
из схемы сборки модулей perl. "Мне нравится" :-)

> При условии, что версия ABI для каждого модуля и зависимостей на него
> будет прописана жёстко, например, предложенным мной способом, проблем
> с зависимостями быть не должно.
Ну, это уже не вопрос, все понимают, что любая предложенная схема должна
в любом случае гарантировать привязку к ABI.

> Загвоздка в том, что .src.rpm не зависит от опций --with и --enable.
> Должно быть однозначное соответствие между .spec и .src.rpm,
> иначе получаются пакеты с разными именами, не отличающиеся ни
> одним байтом.
BTW, я, кажется, знаю, как сделать так, чтобы отличались :-).
Рассказывать? :-)

> Итак, я предлагаю не уродовать имена в общем случае, оставив эту
> практику для сборок отдельных модулей, по каким-либо причинам нужных
> под старый python, когда уже есть тот же модуль под новый. И уж в
> этом случае делать и отдельный .src.rpm.
В общем, тут проблема-то не в том, что есть "старый" питон, и "новый" питон.
В нормальных условиях, после переезда, есть только один питон (плюс, желающие
держать у себя _локально_ старый питон, но они сами себе злобные буратины,
хоть мы и подумаем и о них тоже).

Но проблема в том, чтобы на время _каждого_ переезда иметь возможность
сохранить в Сизифе хотя бы одну работающую версию. Как сейчас видится
переезд мне (и, надеюсь, Андрею):

	* Сборщик питона (Андрей) видит, что появилась новая версия, и
	  собирает пакет вида python-X.Z-alt*.i586.rpm

	* Кроме этого, он в АВТОМАТИЧЕСКОМ режиме собирает пакет
	  pythonXY-X.Y-alt*.i586.rpm и ВСЕ пакеты модулей, присутствующие
	  на данный момент в Сизифе как pythonXY-pyModule-*
	  
	* Затем все это хозяйство апдлоадится в Сизиф (возможно, все
	  pythonXY-* едут куда-нибудь в RPMS.obsolete или навроде этого)
	  и бросается клич: налетай, ребята!
	  
	* Ребята начинают пересобирать модули под новый питон. В какой-то
	  момент количество модулей под новый питон достигает какого-либо
	  критического значения и/или наступает "час Ч" (но он наступает
	  _не сразу_ в момент заливки нового питона!) и старый питон
	  выносится из репозитория вовсе.

Данная схема может варьироваться. Например, объявляется, что трудности
индейцев вождя не ...., и [автоматической] пересборкой модулей под старый
питон конечные пользователи Сизифа занимаются сами (хотя это было грустно,
все-таки, по факту, люди _пользуются_ Сизифом, и ставить им палки в колеса,
лишая среды разработки на месяц-другой, было бы, мягко говоря, неразумно.

Впрочем, все это не нужно будет, если, например, удастся договориться, что
с момента сборки Андреем нового питона до полной пересборки всех модулей будет
происходить, скажем, не более недели. Реально?


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: Q: Python packaging howto

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

Hello Alexey,

On Mon, Feb 23, 2004 at 07:20:37AM +0600, Alexey Morozov wrote:
>
> > Загвоздка в том, что .src.rpm не зависит от опций --with и --enable.
> > Должно быть однозначное соответствие между .spec и .src.rpm,
> > иначе получаются пакеты с разными именами, не отличающиеся ни
> > одним байтом.
> BTW, я, кажется, знаю, как сделать так, чтобы отличались :-).
> Рассказывать? :-)

Расскажите, но, боюсь, это не нужно большинству модулей в Sisyphus.

> Но проблема в том, чтобы на время _каждого_ переезда иметь возможность
> сохранить в Сизифе хотя бы одну работающую версию. Как сейчас видится
> переезд мне (и, надеюсь, Андрею):
> 
> 	* Сборщик питона (Андрей) видит, что появилась новая версия, и
> 	  собирает пакет вида python-X.Z-alt*.i586.rpm
> 
> 	* Кроме этого, он в АВТОМАТИЧЕСКОМ режиме собирает пакет
> 	  pythonXY-X.Y-alt*.i586.rpm и ВСЕ пакеты модулей, присутствующие
> 	  на данный момент в Сизифе как pythonXY-pyModule-*

Тут, по-моему, лучше такой шаг: сборщик в автоматическом режиме
собирает все модули под новый python. Те и только те модули,
которые не собираются, плюс их зависимости, собираются под старый python
с legacy префиксом, прописываемым явно или с помошью вспомогательных
макросов в spec -- чтобы избежать головной боли в hasher.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: Python packaging howto

[Alexey Morozov]

[-- Attachment #1: Type: text/plain, Size: 5726 bytes --]

On Sat, Feb 21, 2004 at 09:25:33PM +0300, Mikhail Zabaluev wrote:
> Мне не нравится идея, что основное имя (то, которое принимает
> .src.rpm) зависит от ключей сборки. На самом-то деле исходный
> пакет от этого не зависит.
Ну, мне тоже не слишком нравится.

> Может быть, лучше для Name: оставить имя модуля, без всяких python*-,
> а для объявления бинарного пакета предусмотреть макросы? Впрочем,
> это будет не очень удобно, если макрос для объявления бинарного пакета
> не будет автоматически копировать %description основного пакета.
> Я не знаю, можно ли это сделать в rpm.
Вот именно потому, что я тоже не знаю, я и пошел по пути наименьшего
сопротивления.

> Есть ещё такая радикальная идея: бинарный пакет может именоваться и
> по-человечески, именем tarball'а, но предоставлять также имя,
> привязанное к версии ABI python. При этом могут использоваться
> скобочные схемы, например:
> python-abi(%modulename) = %__python_version
> 
> После этого корректное прописывание зависимостей между пакетами
> модулей останется предметом policy.
Хочется не только решить проблему с зависимостями, но и решить проблему
с неединовременным перетеканием всего питоньего хозяйства из одной версии
в другую.

> > Requires: python%__python_package_version-<anotherModule>
> > 
> > Могу оформить все это дело в виде отдельного макроса. Предложения по
> > наименованию принимаются.
> 
> Помимо изложенного выше предложения, есть такой вариант:
> 
> %{python_versioned_name anotherModule}
> 
> а также
> %__python_packagename python%__python_package_version
Ну, ждем, пока остальные выскажутся. Мне, в общем, в данном случае,
практически все равно, куда копать.

> Насколько я понимаю, компиляция после %install необходима только для
> тех скриптов, которые не используют схему установки из distutils
> с опцией --root. Если так, то да, лучше её отключить.
Да.

> По идее, нужно добиться, чтобы RPM_PYTHON была установлена правильно
> во всех случаях.
Ну, я надеюсь, что это так (в смысле, уже установлена)

> Как насчёт %set_python_version по примеру autoconf/automake/libtool?
> Тогда /usr/bin/python из python-common запустит требуемую версию
> или контролируемый альтернативами /usr/bin/python-default.
> 
> Этот же трюк позволит избавиться от --with-pythonXY и таинственного
> макроса setup_python_module: тем, кто захочет зафиксировать версию
> python в своей сборке, достаточно будет вставить
> %set_python_version X.Y в spec
Нет. В спеке НЕ НУЖНО указывать версию питона, потому что в итоге хотелось
добиться возможности сборки модуля под требуемую версию питона МИНИМАЛЬНЫМИ
телодвижениями 

> > У меня есть идея оформить стандартные действия при инсталляции макросами,
> > аналогичными %perl_vendor_build/%perl_vendor_install, которые бы покрывали
> > основные нужды сборщиков (при использовании distutils). Вероятно, сегодня
> > ближе к вечеру это будет сделано. Скорее всего, по умолчанию будут
> > паковаться только .pyo, но, надеюсь :-), будет возможность, во-первых,
> > собрать [отдельный] пакет с .py, а, во-вторых, переключиться на
> > использование .pyc.
> 
> Достаточно определить макрос для уровня оптимизации, %python_optlevel,
> и использовать его в опции --optimize (с разумным fallback'ом).
Не только. Нужно еще понять, выделять ли в отдельный пакет (автоматически,
разумеется) .py.

> > в данной схеме есть один, как мне кажется, недочет. Если некто
> > пересобирает модуль вида pythonXY-pyModule-K.L.M-altN.src.rpm, не
> > указывая --with pythonXY, то на выходе он получает модуль, привязанный к
> > ТЕКУЩЕЙ версии питона, а не к версии X.Y. Имена и зависимости пакетов
> > изменяются соответственно (то есть, будет
> > python-pyModule-K.L.M-altN.i586.rpm, зависящий от python, запускаемого
> > как /usr/bin/python).
> Мне кажется, бинарный пакет с модулем должен всегда быть привязан
> к конкретной версии python ABI, коль скоро он содержит байт-код
> под этот ABI.
Да, конечно. На самом деле, "...зависящий от python,запускаемого..." стоит
переписать как "... зависящий от python, который запускался в момент сборки
пакета как /usr/bin/python".

> Точно так же, нет смысла в общем имени каталога /usr/lib/python
Есть. Для исходников (.py). Они НЕ БУДУТ использоваться напрямую,
а просто для "напосмотреть".

> > %build
> > mkdir -p buildroot
> > 
> > # Unfortunately build and install steps should be done at once
> > # because otherwise .pyo files won't get into INSTALLED_FILES
> > # record
> > 
> > CFLAGS="%optflags" %__python setup.py \
> > 	install --optimize=2 \
> > 		--root=`pwd`/buildroot \
> > 		--record=INSTALLED_FILES
> > %install
> > 
> > cp -pr buildroot %buildroot/
> Не увидел проблем при использовании обычной схемы:
Ну, это место я еще не оптимизировал. К тому же, я игрался на 2.2, там,
помнится, что-то странное происходило в этом месте. Ну и, я пока не понял,
как отнести управляемую байт-компиляцию в %build stage.

> %build
> CFLAGS="$RPM_OPT_FLAGS" python setup.py build
>
> %install
> python setup.py install \
>        --optimize=%python_optlevel \
>        --root=$RPM_BUILD_ROOT \
>        --record=INSTALLED_FILES
Ну и не python, а %__python, все-таки.

> .pyo и .pyc исправно попадают в INSTALLED_FILES.
> Проверял, правда, только на 2.3.
Да, там все нормально.

> P.S. Залил в Sisyphus python-doc версии 2.3.3. Было бы неплохо, если
> бы maintainer Python своевременно обновлял также и этот пакет.
> Там можно прочитать о хорошем способе генерации начального .spec
> для модуля:
> python setup.py bdist_rpm --spec-only
Посмотрите на libAltDist :-)

> Я думаю, об этом стоит написать в HOWTO.
> А может быть, даже подправить шаблон для .spec'а для того, чтобы
> он получался сразу готовым к употреблению.
Уже подправили. Только мне не очень понравилось качество кодирования.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: Q: Python packaging howto

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]

Hello Alexey,

On Sun, Feb 22, 2004 at 06:05:00AM +0600, Alexey Morozov wrote:
>
> > Есть ещё такая радикальная идея: бинарный пакет может именоваться и
> > по-человечески, именем tarball'а, но предоставлять также имя,
> > привязанное к версии ABI python. При этом могут использоваться
> > скобочные схемы, например:
> > python-abi(%modulename) = %__python_version
> > 
> > После этого корректное прописывание зависимостей между пакетами
> > модулей останется предметом policy.
> Хочется не только решить проблему с зависимостями, но и решить проблему
> с неединовременным перетеканием всего питоньего хозяйства из одной версии
> в другую.

Эта проблема решается другими, нетехническими, средствами.
Правильно прописанные зависимости лишь позволят избежать иллюзии,
что у вас есть необходимый вашему приложению модуль, когда
под используемую версию python его нет.

> > Достаточно определить макрос для уровня оптимизации, %python_optlevel,
> > и использовать его в опции --optimize (с разумным fallback'ом).
> Не только. Нужно еще понять, выделять ли в отдельный пакет (автоматически,
> разумеется) .py.

Этого делать не нужно.

> > Точно так же, нет смысла в общем имени каталога /usr/lib/python
> Есть. Для исходников (.py). Они НЕ БУДУТ использоваться напрямую,
> а просто для "напосмотреть".

А отладчик их там найдёт, если байт-код грузится из /usr/lib/python2.3?

> > > %build
> > > mkdir -p buildroot
> > > 
> > > # Unfortunately build and install steps should be done at once
> > > # because otherwise .pyo files won't get into INSTALLED_FILES
> > > # record
> > > 
> > > CFLAGS="%optflags" %__python setup.py \
> > > 	install --optimize=2 \
> > > 		--root=`pwd`/buildroot \
> > > 		--record=INSTALLED_FILES
> > > %install
> > > 
> > > cp -pr buildroot %buildroot/
> > Не увидел проблем при использовании обычной схемы:
> Ну, это место я еще не оптимизировал. К тому же, я игрался на 2.2, там,
> помнится, что-то странное происходило в этом месте. Ну и, я пока не понял,
> как отнести управляемую байт-компиляцию в %build stage.

Надо перепроверить. Байт-компиляция происходит в %install стадии, по
команде install, и разработчики distutils не имеют ничего против:
фактически, это действительно подготовка установленного модуля к
работе с полной оптимизацией. В %build собираются лишь бинарные
расширения.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
Getting the job done is no excuse for not following the rules.

Corollary:
	Following the rules will not get the job done.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: Q: Python packaging howto

[Alexey Morozov]

[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]

On Mon, Feb 23, 2004 at 01:05:37AM +0300, Mikhail Zabaluev wrote:
> > Хочется не только решить проблему с зависимостями, но и решить проблему
> > с неединовременным перетеканием всего питоньего хозяйства из одной версии
> > в другую.
> Эта проблема решается другими, нетехническими, средствами.
Какими? Нет, правда, если будет озвучено, как это можно делать
_на самом_ деле, и это нетехническое решение будет устраивать всех и не
потребует никаких доп. механизмов, то давайте действовать административно.
Думаете, мне очень хочется чувствовать себя мачо rpm macro language
программирования? ;-)

Но я, например, пока не понимаю, как возможно в нынешнем состоянии ALT
взять и всем организованно уехать на новую версию питона и всех его либ.
Ну, кроме нескольких успешных по факту, но довольно болезненных в процессе,
примеров от Сами Знаете Кого :-). 2ldv: no offense и всё такое :-).

> Правильно прописанные зависимости лишь позволят избежать иллюзии,
> что у вас есть необходимый вашему приложению модуль, когда
> под используемую версию python его нет.
Про это и возражений никаких нет.

> 
> > > Достаточно определить макрос для уровня оптимизации, %python_optlevel,
> > > и использовать его в опции --optimize (с разумным fallback'ом).
> > Не только. Нужно еще понять, выделять ли в отдельный пакет (автоматически,
> > разумеется) .py.
> Этого делать не нужно.
Почему? Андрей придерживается противоположного мнения, у него есть
причины на это. У меня самого таких причин на данный момент нет, поэтому
мне скорее все равно. Поэтому, давайте договариваться.

> > > Точно так же, нет смысла в общем имени каталога /usr/lib/python
> > Есть. Для исходников (.py). Они НЕ БУДУТ использоваться напрямую,
> > а просто для "напосмотреть".
> А отладчик их там найдёт, если байт-код грузится из /usr/lib/python2.3?
Да, это хороший вопрос, пока не знаю. Вообще, don't use debugger, feel
the power, Luke :-)

> > Ну, это место я еще не оптимизировал. К тому же, я игрался на 2.2, там,
> > помнится, что-то странное происходило в этом месте. Ну и, я пока не понял,
> > как отнести управляемую байт-компиляцию в %build stage.
> Надо перепроверить. Байт-компиляция происходит в %install стадии, по
> команде install, и разработчики distutils не имеют ничего против:
Ну и фиг с ним тогда. Я это писал уже довольно давно, когда у меня было
слишком много привычек от "настоящих" языков.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: Q: Python packaging howto

[Andrey Orlov]

On Monday 23 February 2004 03:46, Alexey Morozov wrote:
> > Этого делать не нужно.
>
> Почему? Андрей придерживается противоположного мнения, у него есть
> причины на это. У меня самого таких причин на данный момент нет, поэтому
> мне скорее все равно. Поэтому, давайте договариваться.

Основное мое мнение на эту тему - это не вопрос текущего перехода, и его
обсуждение хотелось бы сдвинуть на две недели позже.

> > > > Точно так же, нет смысла в общем имени каталога /usr/lib/python

Господа, я немножко поиграл в это, прочтите FAQ. Я __правда__ все это проверил.
И важно не только "посмотреть", некоторая часть жизненного цикла питоновских кодов,
к сожалению, иногда очень четко зависит от наличия исходников, так что  исходники 
всегда должны кластся туда же, куда бы они легли при нормальной установке. 
Иначе будет __очень__ много никому ненужных сложностей. Всегда должна
быть возможность вернуть среду в "стандартное" состояние, пусть и установкой доп. пакетов.

> > А отладчик их там найдёт, если байт-код грузится из /usr/lib/python2.3?

Нет конечно. Если имеется ввиду отладчик на уровне исходного кода, который
использует idle. Я-то такими инструментами не пользуюсь практически. А вот
всю остальную отладочную информацию (в т.ч. docstring) содержат файлы
pyc, и для отладки их вполне достаточно.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

[devel] Re: Q: Python packaging howto

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

Hello Andrey,

On Mon, Feb 23, 2004 at 09:19:23AM +0300, Andrey Orlov wrote:
>
> > > А отладчик их там найдёт, если байт-код грузится из /usr/lib/python2.3?
> 
> Нет конечно. Если имеется ввиду отладчик на уровне исходного кода, который
> использует idle.

pdb? Я имел в виду это.

> Я-то такими инструментами не пользуюсь практически. А вот
> всю остальную отладочную информацию (в т.ч. docstring) содержат файлы
> pyc, и для отладки их вполне достаточно.

Хотелось бы и навигацию по исходным текстам в отладчике оставить.
Без неё трудно. И комментарии в .pyc, держу пари, не сохраняются :)
В-общем: не надо решать не ту проблему. Use python 2.3 & zip.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
Hope this helps some, sorry for not being able to do a brain dump.

	- Mike Stump helping a clueless user on the gcc mailing list

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: Q: Python packaging howto

[Andrey Orlov]

On Tuesday 24 February 2004 02:12, Mikhail Zabaluev wrote:
> Хотелось бы и навигацию по исходным текстам в отладчике оставить.
> Без неё трудно. И комментарии в .pyc, держу пари, не сохраняются :)

Она остается, никто не мешает поставить исходники при
необходимости отладки.

> В-общем: не надо решать не ту проблему. Use python 2.3 & zip.

Отвечено в привате.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

[devel] Re: Q: Python packaging howto

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

Hello Alexey,

On Mon, Feb 23, 2004 at 06:46:34AM +0600, Alexey Morozov wrote:
>
> Но я, например, пока не понимаю, как возможно в нынешнем состоянии ALT
> взять и всем организованно уехать на новую версию питона и всех его либ.

И поэтому нужно придумать сложное техническое решение организационной
проблемы? :)

> > > > Точно так же, нет смысла в общем имени каталога /usr/lib/python
> > > Есть. Для исходников (.py). Они НЕ БУДУТ использоваться напрямую,
> > > а просто для "напосмотреть".
> > А отладчик их там найдёт, если байт-код грузится из /usr/lib/python2.3?
> Да, это хороший вопрос, пока не знаю. Вообще, don't use debugger, feel
> the power, Luke :-)

Я достаточно давно тружусь в отрасли, чтобы в это не верить :)

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
Workers of the world, arise!  You have nothing to lose but your chairs.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: Q: Python packaging howto

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

On Tue, Feb 24, 2004 at 02:16:23AM +0300, Mikhail Zabaluev wrote:
> > Но я, например, пока не понимаю, как возможно в нынешнем
> > состоянии ALT взять и всем организованно уехать на новую
> > версию питона и всех его либ.
> И поэтому нужно придумать сложное техническое решение
> организационной проблемы? :)

Как показывает практика, порой это реальнее.  Хоть и криво.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: Python packaging howto

[Andrey Orlov]

On Saturday 21 February 2004 21:25, Mikhail Zabaluev wrote:

> P.S. Залил в Sisyphus python-doc версии 2.3.3. Было бы неплохо, если
> бы maintainer Python своевременно обновлял также и этот пакет.

Хорошо. Тем более, что я давно хотел вам об этом написать.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

Re: [devel] Q: Python packaging howto

[Andrey Orlov]

On Saturday 21 February 2004 14:37, Alexey Morozov wrote:
> Данные макросы никак не затрагивают эту область. То есть, метод
> сборки и упаковки определяется исключительно пэкеджером. Единственное
> условие - делать в конце %install unset RPM_PYTHON, чтобы исключить
> скорее всего нежелательную (повторную) байт-компиляцию. Хотя, конечно,
> сейчас этот самый RPM_PYTHON, по-хорошему, будет указывать именно на ту
> версию питона, для которой собирается пакет (даже если идет сборка по
> умолчанию)

А этот пункт, интересно, откуда? Я, кажется, писал, что проверка показала - удаление
ошибки в одном месте оставило ошибку в другом месте, так что повторная байт-компиляция,
по-прежнему, желательна. Кроме того, если вы действительно
пользуетесь INSTALL_FILES от setup.py, то повторная байт компиляция хотя и может
привести к компиляции лишних файлов, тем не менее не приведет к включению их в пакет.
Так что без явной необходимости байт-компиляцию лучше не трогать. Чбы ее упорядочить
и "улучшить" я собираюсь предпринять некоторые шаги.

> Я тут уже высказывал сомнения в практической реальности такого "Часа Ч".
> Вкратце: не все питоньи модули можно пересобрать в тот же момент, когда
> появляется новая версия питона. Пример - Zope, который его создателям и
> Андрею понадобилось патчить для обеспечения функционирования под
> python2.3. Как следствие, "Час Ч" растягивается по времени месяца на

Zope - очень __неудачный__ пример, так как Zope первым из всех пакетов
перешел на python23, это остальные пакейджеры немножко тормозили.

> в данной схеме есть один, как мне кажется, недочет. Если некто
> пересобирает модуль вида pythonXY-pyModule-K.L.M-altN.src.rpm, не
> указывая --with pythonXY, то на выходе он получает модуль, привязанный к
> ТЕКУЩЕЙ версии питона, а не к версии X.Y. Имена и зависимости пакетов
> изменяются соответственно (то есть, будет
> python-pyModule-K.L.M-altN.i586.rpm, зависящий от python, запускаемого
> как /usr/bin/python).

Это нормально, я не вижу, в чем проблема? Мало того, по нашей полиси,
которую я сейчас свожу воедино, это единственный правильный метод
сборки и расстановки зависимостей.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

Re: [devel] Q: Python packaging howto

[Andrey Orlov]

On Saturday 21 February 2004 14:37, Alexey Morozov wrote:
> > Вообще вся затея обеспечить постепенную миграцию может принести
> > больше проблем, чем разовая смена всех модулей в день Д с
> > предварительной подготовкой, возложенной на packager'ов.

Нет проблемы. Просто у вас не пройдет апдейт и все. Поймите меня 
правильно, я тоже против постепенной миграции и склонен переходить
как можно быстрее на новый питон, но в данном случае проблемы, как таковой,
у нас не будет.


-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

Re: [devel] Q: Python packaging howto

[Andrey Orlov]

On Saturday 21 February 2004 14:37, you wrote:
> В аттачменте файл python, который, по-хорошему, идет в python-common
> и пример спек файла. Собирать при помощи
>
> rpmbuild -ba pyserial.spec

Я посмотрел спек. Пожалуй, мне кое-что не понравилось, это мелочь, но все же.
Если я правильно помню как работает rpm, то вот это:

%files -f INSTALLED_FILES
%doc changes.txt readme.txt

%files -n python-%modulename-doc
%doc examples

Приведет к тому, что changes.txt & readme.txt попадут в /usr/share/doc/python-module,
а examples - в /usr/share/doc/python-module-doc. Что, в общем, неудобно.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

[devel] [JT] Re: Q: Python packaging howto

[Michael Shigorin]

On Fri, Feb 20, 2004 at 03:00:41PM +0300, Mikhail Zabaluev wrote:
> Вообще вся затея обеспечить постепенную миграцию может принести

...мигрень.  Болезнь мигрирующих. :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/