From: Alexey Morozov <alex-altlinux@idisys.iae.nsk.su> To: Mikhail Zabaluev <mhz@altlinux.org>, devel@altlinux.ru Cc: cray@neural.ru Subject: Re: [devel] Q: Python packaging howto Date: Sat, 21 Feb 2004 17:37:26 +0600 Message-ID: <20040221113726.GB29390@pyro.hopawar.private.net> (raw) In-Reply-To: <20040220120041.GA2684@av1046.comex.ru> [-- 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 --]
next prev parent reply other threads:[~2004-02-21 11:37 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-02-20 12:00 Mikhail Zabaluev 2004-02-20 12:04 ` Klimchev Konstantin 2004-02-20 13:45 ` Andrey Orlov 2004-02-21 11:37 ` Alexey Morozov [this message] 2004-02-21 18:25 ` Mikhail Zabaluev 2004-02-21 19:14 ` Dmitry V. Levin 2004-02-22 0:26 ` Alexey Morozov 2004-02-22 19:59 ` [devel] " Mikhail Zabaluev 2004-02-22 20:15 ` Andrey Orlov 2004-02-23 22:58 ` Mikhail Zabaluev 2004-02-23 1:20 ` Alexey Morozov 2004-02-23 23:05 ` Mikhail Zabaluev 2004-02-22 0:05 ` [devel] " Alexey Morozov 2004-02-22 22:05 ` [devel] " Mikhail Zabaluev 2004-02-23 0:46 ` Alexey Morozov 2004-02-23 6:19 ` Andrey Orlov 2004-02-23 23:12 ` Mikhail Zabaluev 2004-02-24 7:28 ` Andrey Orlov 2004-02-23 23:16 ` Mikhail Zabaluev 2004-02-24 10:53 ` Michael Shigorin 2004-02-22 7:18 ` [devel] " Andrey Orlov 2004-02-22 13:39 ` Andrey Orlov 2004-02-22 13:40 ` Andrey Orlov 2004-02-22 16:20 ` Andrey Orlov 2004-02-22 17:58 ` [devel] [JT] " Michael Shigorin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20040221113726.GB29390@pyro.hopawar.private.net \ --to=alex-altlinux@idisys.iae.nsk.su \ --cc=cray@neural.ru \ --cc=devel@altlinux.ru \ --cc=mhz@altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git