[devel] Q: Python packaging howto

Сб Фев 21 14:37:26 MSK 2004

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). Такая возможность интересна?

----------- следующая часть -----------
# -*- 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
----------- следующая часть -----------
%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})
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20040221/b27db373/attachment-0001.bin>