Правила упаковки Python (эпохи 201x)

Эти правила были заменены более новой версией.

Они существуют как исторический справочник для пакетов, которые ещё не следуют новым рекомендациям.

Поддержка версий Python

В Fedora существует несколько сред выполнения Python — по одной для каждого поддерживаемого основного выпуска Python. На данный момент это одна для python3.x и одна для python2.7. Однако стек Python 2 будет удалён из Fedora и устарел. Официальная поддержка интерпретатора python2 со стороны upstream заканчивается в 2020 году. Если программное обеспечение поддерживает python3, оно ДОЛЖНО быть упаковано для python3. Программное обеспечение, использующее python2, НЕ ДОЛЖНО быть впервые упаковано в Fedora без исключения FESCo.

Правила сопровождения уже существующих пакетов python2 см. в приложении.

Несколько сред выполнения Python

В Fedora /usr/bin/python, если он установлен, является символической ссылкой на /usr/bin/python3. В предыдущих выпусках это была символическая ссылка на /usr/bin/python2.

Пакеты в Fedora НЕ ДОЛЖНЫ использовать /usr/bin/python. Вместо этого пакеты для Python 3 ДОЛЖНЫ использовать /usr/bin/python3 (даже если upstream поддерживает и Python 2, и Python 3). Вследствие этого /usr/bin/python (а также /usr/bin/env python и подобные) НЕ ДОЛЖНЫ использоваться в строках shebang или в качестве зависимости пакета. Все случаи использования неверсионированных исполняемых файлов python в строках shebang приведут к сбою сборки. Такие shebang ДОЛЖНЫ быть исправлены (например, с помощью макроса %py3_shebang_fix в spec-файле). Если необходимо отключить проверки, см. информацию в Строках shebang.

Все среды выполнения Python имеют виртуальный provides python(abi) = $MAJOR.$MINOR. Например, пакет среды выполнения Python 3.7 имеет:

$ rpm -q --provides python3 | grep abi
python(abi) = 3.7

Модули Python, использующие эти среды выполнения, должны иметь соответствующую строку «Requires» для среды выполнения Python, с которой они используются. Это делается автоматически для файлов в /usr/lib[^/]*/python${PYVER}

В соответствии с политикой для обычных пакетов, подпакеты вашего пакета, специфичные для версии Python, НЕ ДОЛЖНЫ удаляться в ветке выпуска Fedora.

Именование

Исходный пакет для библиотеки Python ДОЛЖЕН быть назван с префиксом python-. Однако собранный пакет должен включать основную версию Python в имени, используя префикс python3-. Это достигается путём добавления подпакета. См. пример ниже.

Это правило не применяется к приложениям.

Символ ` в именах собранных пакетов (т.е. не-SRPM), содержащих каталоги `.dist-info` или `.egg-info`, зарезервирован для <<Python Extras>> и НЕ ДОЛЖЕН использоваться для каких-либо других целей. Символ ` активирует автоматический генератор зависимостей для extras. Замените любые знаки ` в имени upstream на `-` или опустите их, если они стоят в начале имени. В качестве исключения символы ` допускаются в конце имени.

Зависимости

Пакетам, собираемым для Python 3, потребуется BuildRequires: python3-devel. Большинству из них также потребуется BuildRequires: python3-setuptools. В случае сомнений проверьте файл setup.py на наличие импорта setuptools.

Пакеты НЕ ДОЛЖНЫ иметь зависимостей (ни во время сборки, ни во время выполнения) от пакетов, названных с неверсионированным префиксом python-. Зависимости от пакетов Python вместо этого ДОЛЖНЫ использовать имена, начинающиеся с python3-.

Автоматически генерируемые зависимости

Пакеты МОГУТ использовать автоматический генератор зависимостей Python. Этот генератор использует метаданные egg/dist из upstream (такие как install_requires из setuptools) для определения зависимостей пакета. Генератор разбирает установленные метаданные из /usr/lib(64)?/pythonX.Y/site-packages/[^/]+.(egg|dist)-info/requires.txt, поэтому он не будет работать с программным обеспечением, использующим чистый distutils.

Это генерирует зависимости времени выполнения в форме pythonX.Ydist(foo). Если сгенерированные зависимости неточны, дополнительные всё ещё можно добавить вручную. Чтобы удалить некоторые, упаковщик МОЖЕТ изменить предоставленные upstream метаданные (обычно указанные в файле setup.py) в разделе %prep spec-файла или прибегнуть к фильтрации этих зависимостей.

Упаковщик ДОЛЖЕН проверить сгенерированные зависимости на корректность. Все зависимости ДОЛЖНЫ разрешаться в целевой версии Fedora.

В качестве примера, пакет notebook из upstream имеет (по состоянию на версию 5.6.0):

install_requires = [
    'jinja2',
    'tornado>=4',
    'pyzmq>=17',
    'ipython_genutils',
    'traitlets>=4.2.1',
    'jupyter_core>=4.4.0',
    'jupyter_client>=5.2.0',
    'nbformat',
    'nbconvert',
    'ipykernel',
    'Send2Trash',
    'terminado>=0.8.1',
    'prometheus_client'
],

И получившиеся зависимости:

python3.7dist(ipykernel)
python3.7dist(ipython-genutils)
python3.7dist(jinja2)
python3.7dist(jupyter-client) >= 5.2
python3.7dist(jupyter-core) >= 4.4
python3.7dist(nbconvert)
python3.7dist(nbformat)
python3.7dist(prometheus-client)
python3.7dist(pyzmq) >= 17
python3.7dist(send2trash)
python3.7dist(terminado) >= 0.8.1
python3.7dist(tornado) >= 4
python3.7dist(traitlets) >= 4.2.1

Обратите внимание, что суффиксы .0 удаляются из номеров версий, чтобы соответствовать поведению инструментов Python. (PEP 440 устанавливает, что X.Y и X.Y.0 считаются равными.)

Этот генератор включён по умолчанию в Fedora. Если упаковщик желает явно отказаться от генератора, поскольку метаданные upstream не применимы, упаковщику СЛЕДУЕТ явно отказаться, добавив:

%{?python_disable_dependency_generator}

Хотя этот оператор можно использовать в любом месте spec-файла, мы рекомендуем размещать его непосредственно перед объявлением %description основного пакета.

Python Extras

Python extras — это способ для проектов Python объявить, что для дополнительной функциональности требуются дополнительные зависимости.

Например, requests имеет несколько стандартных зависимостей (например, urllib3). Но он также объявляет extra с именем requests[security], который перечисляет дополнительные зависимости (например, cryptography). В отличие от подпакетов RPM, extras могут указывать только дополнительные зависимости, а не дополнительные файлы. Основной пакет будет работать, если необязательная зависимость не установлена, но его функциональность может быть ограничена.

Инструменты Python рассматривают extras как виртуальные пакеты. Например, если пользователь запускает pip install requests[security] или устанавливает проект, зависящий от requests[security], будут установлены и requests, и cryptography.

Начиная с Fedora 33, extras обычно предоставляются пакетами без файлов. Вместо квадратных скобок в именах пакетов Fedora по соглашению используется символ + для разделения имени пакета и имени extra, например, пакет будет называться python3-requests+security. Знак плюс допустим в именах RPM-пакетов, но не в канонических именах проектов Python и не в идентификаторах extras.

Пакеты Python СЛЕДУЕТ снабжать Provides для всех extras, указанных проектом upstream, за исключением тех, которые бесполезны для других пакетов (например, требования для сборки/разработки, обычно называемые dev, doc или test).

Пакет, предоставляющий Python extra, ДОЛЖЕН предоставлять python3dist(…[…]) и python3.Xdist(…[…]), например, python3.9dist(requests[security]). Эти требования СЛЕДУЕТ генерировать с помощью автоматического генератора зависимостей.

Пакет, предоставляющий Python extra, ДОЛЖЕН требовать основной пакет extra с точным NEVR.

Подпакет, который в первую очередь предоставляет один Python extra, СЛЕДУЕТ называть, добавляя + и имя extra к имени основного пакета. Например, python3-requests+security.

Самый простой способ предоставить extra — это выделенный подпакет, не содержащий файлов («метапакет»). Этот случай можно автоматизировать с помощью макроса %python_extras_subpkg.

Альтернативный подход: когда какой-то extra всегда полезен в дистрибутиве, он может предоставляться основным пакетом; когда несколько extras связаны между собой, они могут предоставляться одним подпакетом. Однако наличие отдельного подпакета для каждого extra позволяет использовать автоматический генератор зависимостей, чтобы гарантировать, что требования extras будут синхронизированы с upstream. Если вы создаёте выделенный подпакет и хотите, чтобы он всегда/обычно устанавливался, вы МОЖЕТЕ указать для него Require/Recommend/Suggest из основного пакета.

Генератор зависимостей для extras активируется, если выполняется следующее:

Пакет должен содержать каталог .egg-info/.dist-info, обычно как %ghost.
Имя пакета должно заканчиваться на +EXTRA (где EXTRA — имя extra).

В качестве примера подпакет extra для requests[security] можно указать с помощью удобного макроса %python_extras_subpkg следующим образом. Макрос принимает имя основного пакета и имя (имена) extra, а также путь к каталогу .egg-info или .dist-info:

%{?python_extras_subpkg:%python_extras_subpkg -n python3-requests -i %{python3_sitelib}/*.egg-info security}

В этом случае генератор зависимостей extras прочитает метаданные upstream из каталога .egg-info. Если он обнаружит, что extra security имеет зависимость от cryptography, он сгенерирует Requires: python3.Xdist(cryptography), Provides: python3dist(requests[security]) (и соответствующий вариант python3.Xdist).

Если вам нужны дополнительные возможности, которые не покрывает макрос %python_extras_subpkg, вам придётся написать разделы подпакета вручную. Такими возможностями могут быть, например:

Устаревание/предоставление других имён (например, устаревших пакетов extras)
Ручные сильные или слабые зависимости от других (возможно, не-Python) пакетов
Включение файлов, исключённых из основного пакета (если такие файлы имеют смысл только с extra и базовый пакет не даёт сбоев без них)

В качестве примера того, что нужно написать в этих случаях, приведённый выше вызов макроса %python_extras_subpkg разворачивается в следующее:

%package -n python3-requests+security
Summary: Metapackage for python3-requests: security extras
Requires: python3-requests = %{?epoch:%{epoch}:}%{version}-%{release}
%description -n python3-requests+security
This is a metapackage bringing in security extras requires for python3-requests.
It contains no code, just makes sure the dependencies are installed.

%files -n python3-requests+security
%ghost %{python3_sitelib}/*.egg-info

Обратите внимание, что генератор зависимостей не добавляет зависимость от основного пакета (Requires: python3-setuptools_scm = ... выше). Если вы не используете макрос %python_extras_subpkg, вам нужно добавить её вручную.

%python_extras_subpkg может принимать несколько имён extras для генерации нескольких пакетов. Дополнительные параметры см. в предложении об изменении, которое это ввело.

Provides

Для любого модуля foo, предназначенного для использования в Python 3 с помощью import foo, пакет, который его включает, должен предоставлять python3-foo. Это, конечно, всегда так, если подпакет назван python3-foo (как в примерах ниже). Если подпакет имеет другое имя, то Provides: python3-foo следует добавить явно (через %py_provides python3-foo, см. ниже).

Макрос %py_provides

Все пакеты, предоставляющие python3-... (для любого ...), ТАКЖЕ СЛЕДУЕТ предоставлять python-... и python3.X-.... Начиная с Fedora 33, большинство пакетов Python с именем python3-... будут автоматически предоставлять такие имена через генератор зависимостей в /usr/lib/rpm/fileattrs/pythonname.attr.

Любые вручную добавленные виртуальные provides для python3-... СЛЕДУЕТ выполнять через макрос %py_provides.

Вместо:

Provides: python3-pkg_resources = %{version}-%{release}

Сделайте:

%py_provides python3-pkg_resources

При необходимости укажите собственный epoch:version-release в качестве второго аргумента %py_provides.

В выпусках старше Fedora 33 или (по техническим ограничениям) для пакетов без файлов необходимо использовать %py_provides даже для имён пакетов:

%package -n python3-%{srcname}
Summary: %{summary}
%py_provides python3-%{srcname}

Упаковщикам СЛЕДУЕТ попытаться удалить явные вызовы %py_provides для имён пакетов, но они МОГУТ сохранить их, если стремятся к совместимости со старыми выпусками или пакетами без файлов.

Исторически существовал макрос %python_provide с похожей, но иной семантикой. Он всё ещё работает по причинам совместимости, но устарел и НЕ ДОЛЖЕН использоваться, и упаковщикам СЛЕДУЕТ заменять его соответствующим вызовом %py_provides.

Автоматические Provides со стандартизованным именем

При сборке пакета Python RPM ищет файлы или каталоги .dist-info и .egg-info в разделах %files всех пакетов. Если найдены один или несколько, RPM разбирает их, чтобы найти стандартизованное имя (т.е. имя dist, имя на PyPI) упакованного программного обеспечения, а затем автоматически создаёт два тега Provides: в следующем формате:

Provides: python3.Ydist(CANONICAL_STANDARDIZED_NAME)
Provides: python3dist(CANONICAL_STANDARDIZED_NAME)

3.Y — это используемая версия Python (обычно 3.6 и выше), а в скобках — имя программного обеспечения в каноническом формате, используемом инструментами и сервисами Python, такими как setuptools, pip и PyPI. Каноническое имя получается путём приведения стандартизованного имени к нижнему регистру и преобразования всех последовательностей небуквенно-цифровых символов в одиночные символы «-». Пример: «The $$$ Tree» превращается в «the-tree».

Requires и BuildRequires со стандартизованными именами

Эти теги Provides можно использовать для указания Requires и BuildRequires пакета с использованием стандартизованных имён (т.е. имени dist, имени на PyPI) модулей Python. Для удобства вы можете использовать макрос %{py3_dist}, который принимает один или несколько параметров: стандартизованное имя (имена) нужного программного обеспечения Python. Он преобразует имя (имена) в канонический формат и создаст соответствующие теги python3dist(...).

Кроме того, вы можете использовать макрос %{py_dist_name}, который просто преобразует любое стандартизованное имя в канонический формат.

Например:

BuildRequires: %{py3_dist PyMySQL} >= 0.7.5
# => BuildRequires: python3dist(pymysql) >= 0.7.5

Requires: %{py3_dist virtualenv pyPEG2}
# => Requires: python3dist(virtualenv) python3dist(pypeg2)

%{py_dist_name 0-._.-._.-._.-._.-._.-._.-0}
# => 0-0

Исходные файлы с PyPI

При упаковке программного обеспечения, доступного на PyPI, вы можете использовать макрос %pypi_source. Этот макрос принимает от нуля до трёх аргументов и вычисляется в подходящий URL-адрес для исходного файла на PyPI. Аргументы:

Имя проекта на PyPI. По умолчанию %srcname, если определено, или %pypi_name, если определено, или %name (имя пакета).
Версия проекта на PyPI. По умолчанию %version (версия пакета) с удалёнными символами ~ (используются для альфа/бета/dev-версий в версии RPM, но не в версии пакета Python).
Используемое расширение файла. По умолчанию tar.gz.

В большинстве случаев указывать аргументы не требуется.

Макросы

Следующие макросы определены для вас во всех поддерживаемых выпусках Fedora и EPEL:

Макрос Развёрнутый путь Примечания

Макрос	Развёрнутый путь	Примечания
`%{__python}`	(Ошибка)	Не используйте этот макрос без его переопределения. Его определение меняет значение других «неверсионированных» макросов Python, таких как `%{python}` или `%{python_sitelib}`.
`%{__python3}`	`/usr/bin/python3`	Интерпретатор Python 3. Переопределение этого макроса изменяет все макросы `%{python3...}`.
`%{python3}`	`%{__python3}`	Интерпретатор Python 3. Используйте этот макрос в spec-файлах.
`%py_provides`	(Lua-скрипт)	Подробное объяснение см. в [The %py_provides macro].
`%{python3_sitelib}`	`/usr/lib/python3.X/site-packages`	Место установки чистых модулей python3.
`%{python3_sitearch}`	`/usr/lib64/python3.X/site-packages` на 64-битных архитектурах (например, x86_64) и `/usr/lib/python3.X/site-packages` на 32-битных.	Место установки модулей расширения python3 (например, скомпилированных из C).
`%{py_byte_compile}`	(скрипт)	Использование см. в разделе байт-компиляции.
`%{python3_version}`	`3.X`	Версия Python 3. Полезна при запуске программ с версией Python в имени файла, таких как `nosetests-%{python3_version}`.
`%{python3_version_nodots}`	`3X`	Версия Python 3 без точек. Полезна при явном перечислении файлов в разделе %files, например `%{python3_sitearch}/foo/_speedups.cpython-%{python3_version_nodots}*.so`
`%{python3_platform}`	`linux-x86_64` на x86_64	Имя платформы, используемое в Python, полезно для указания `$PYTHONPATH`, например `PYTHONPATH=build/lib.%{python3_platform}-%{python3_version}`
`%{python3_ext_suffix}`	`.cpython-3X-x86_64-linux-gnu.so` на x86_64	Обычный суффикс модулей расширения Python, полезен при перечислении файлов. Обратите внимание, что модули расширения могут также иметь простой суффикс `.so` в зависимости от того, как они собраны.
`%py3_build`	`%{__python3} setup.py build …`	О передаче аргументов в `setup.py build` или напрямую в `setup.py` см. `%py3_install`.
`%py3_install`	`%{__python3} setup.py install --skip-build …`	В `setup.py install` передаются различные флаги, подробности и аналогичные макросы см. в `/usr/lib/rpm/macros.d/macros.python3`. Чтобы добавить дополнительные флаги/аргументы в `setup.py install`, отделите их с помощью `--`, например: `%py3_install -- --install-scripts %{_libexecdir}`. Чтобы передать пользовательские аргументы командной строки напрямую в `setup.py`, определите `%py_setup_args`.
`%__pytest`	`/usr/bin/pytest`	Команда `pytest`, используемая в `%pytest`. Не используйте этот макрос напрямую, но при желании можете переопределить его для использования в `%pytest`.
`%pytest`	`PATH=… PYTHONPATH=… … %{__pytest}`	Устанавливаются различные переменные окружения, чтобы гарантировать тестирование упакованной версии. Используйте этот макрос вместо прямых вызовов `pytest` в `%check`. Передавайте дополнительные аргументы так, как если бы они передавались в `pytest`, например `%pytest -m "not network"`, чтобы исключить тесты, помеченные как `network`.
`%py3_check_import …`	`PATH=… PYTHONPATH=… … %{__python3} -c 'import …'`	Устанавливаются различные переменные окружения, чтобы гарантировать тестирование упакованной версии. Используйте этот макрос в `%check`, чтобы проверить, что публичные модули Python можно импортировать, если запуск набора тестов upstream невозможен. Передавайте имена модулей как позиционные аргументы, разделённые пробелами или запятыми.
`%{py_dist_name}`	(Lua-скрипт)	По заданному стандартизованному имени (т.е. имени dist, имени на PyPI) программного обеспечения Python преобразует его в канонический формат. Дополнительную информацию см. в [Automatic Provides with a standardized name].
`%{py3_dist}`	(Lua-скрипт)	По заданному стандартизованному имени (т.е. имени dist, имени на PyPI) программного обеспечения Python преобразует его в канонический формат и вычисляется в `python3dist(CANONICAL_NAME)`, что полезно при указании зависимостей. Дополнительную информацию см. в [Automatic Provides with a standardized name].
`%{pypi_source}`	(Lua-скрипт)	Вычисляется в подходящий URL-адрес для пакета. Дополнительную информацию см. выше.
`%pycached ….py`	(Lua-скрипт)	По заданному файлу Python перечисляет файл и файлы с его байт-кодом в кэше. Дополнительную информацию см. в [Byte compiling].
`%{py3_shebang_flags}`	`s`	Набор флагов по умолчанию для shebang Python. Переопределите его, чтобы изменить набор. Используется `%py3_shebang_fix`.
`%py3_shebang_fix …`	(скрипт Python)	По заданным путям к файлам Python или каталогам с ними изменяет shebang Python на `#! %{__python3}`, сохраняет любые существующие флаги (если найдены) и добавляет флаги, определённые в `%{py3_shebang_flags}` (если ещё не присутствуют).

%{__python}

(Ошибка)

Не используйте этот макрос без его переопределения. Его определение меняет значение других «неверсионированных» макросов Python, таких как %{python} или %{python_sitelib}.

%{__python3}

/usr/bin/python3

Интерпретатор Python 3. Переопределение этого макроса изменяет все макросы %{python3...}.

%{python3}

%{__python3}

Интерпретатор Python 3. Используйте этот макрос в spec-файлах.

%py_provides

(Lua-скрипт)

Подробное объяснение см. в [The %py_provides macro].

%{python3_sitelib}

/usr/lib/python3.X/site-packages

Место установки чистых модулей python3.

%{python3_sitearch}

/usr/lib64/python3.X/site-packages на 64-битных архитектурах (например, x86_64) и /usr/lib/python3.X/site-packages на 32-битных.

Место установки модулей расширения python3 (например, скомпилированных из C).

%{py_byte_compile}

(скрипт)

Использование см. в разделе байт-компиляции.

%{python3_version}

3.X

Версия Python 3. Полезна при запуске программ с версией Python в имени файла, таких как nosetests-%{python3_version}.

%{python3_version_nodots}

3X

Версия Python 3 без точек. Полезна при явном перечислении файлов в разделе %files, например %{python3_sitearch}/foo/_speedups.cpython-%{python3_version_nodots}*.so

%{python3_platform}

linux-x86_64 на x86_64

Имя платформы, используемое в Python, полезно для указания $PYTHONPATH, например PYTHONPATH=build/lib.%{python3_platform}-%{python3_version}

%{python3_ext_suffix}

.cpython-3X-x86_64-linux-gnu.so на x86_64

Обычный суффикс модулей расширения Python, полезен при перечислении файлов. Обратите внимание, что модули расширения могут также иметь простой суффикс .so в зависимости от того, как они собраны.

%py3_build

%{__python3} setup.py build …

О передаче аргументов в setup.py build или напрямую в setup.py см. %py3_install.

%py3_install

%{__python3} setup.py install --skip-build …

В setup.py install передаются различные флаги, подробности и аналогичные макросы см. в /usr/lib/rpm/macros.d/macros.python3. Чтобы добавить дополнительные флаги/аргументы в setup.py install, отделите их с помощью --, например: %py3_install -- --install-scripts %{_libexecdir}. Чтобы передать пользовательские аргументы командной строки напрямую в setup.py, определите %py_setup_args.

%__pytest

/usr/bin/pytest

Команда pytest, используемая в %pytest. Не используйте этот макрос напрямую, но при желании можете переопределить его для использования в %pytest.

%pytest

PATH=… PYTHONPATH=… … %{__pytest}

Устанавливаются различные переменные окружения, чтобы гарантировать тестирование упакованной версии. Используйте этот макрос вместо прямых вызовов pytest в %check. Передавайте дополнительные аргументы так, как если бы они передавались в pytest, например %pytest -m "not network", чтобы исключить тесты, помеченные как network.

%py3_check_import …

PATH=… PYTHONPATH=… … %{__python3} -c 'import …'

Устанавливаются различные переменные окружения, чтобы гарантировать тестирование упакованной версии. Используйте этот макрос в %check, чтобы проверить, что публичные модули Python можно импортировать, если запуск набора тестов upstream невозможен. Передавайте имена модулей как позиционные аргументы, разделённые пробелами или запятыми.

%{py_dist_name}

(Lua-скрипт)

По заданному стандартизованному имени (т.е. имени dist, имени на PyPI) программного обеспечения Python преобразует его в канонический формат. Дополнительную информацию см. в [Automatic Provides with a standardized name].

%{py3_dist}

(Lua-скрипт)

По заданному стандартизованному имени (т.е. имени dist, имени на PyPI) программного обеспечения Python преобразует его в канонический формат и вычисляется в python3dist(CANONICAL_NAME), что полезно при указании зависимостей. Дополнительную информацию см. в [Automatic Provides with a standardized name].

%{pypi_source}

(Lua-скрипт)

Вычисляется в подходящий URL-адрес для пакета. Дополнительную информацию см. выше.

%pycached ….py

(Lua-скрипт)

По заданному файлу Python перечисляет файл и файлы с его байт-кодом в кэше. Дополнительную информацию см. в [Byte compiling].

%{py3_shebang_flags}

s

Набор флагов по умолчанию для shebang Python. Переопределите его, чтобы изменить набор. Используется %py3_shebang_fix.

%py3_shebang_fix …

(скрипт Python)

По заданным путям к файлам Python или каталогам с ними изменяет shebang Python на #! %{__python3}, сохраняет любые существующие флаги (если найдены) и добавляет флаги, определённые в %{py3_shebang_flags} (если ещё не присутствуют).

Во время %install или при перечислении %files вы можете использовать макросы %{python3_sitearch} и %{python3_sitelib}, чтобы указать, где находятся установленные модули. Например:

%files
# A pure python3 module
%{python3_sitelib}/foomodule/
# A compiled python3 extension module
%{python3_sitearch}/barmodule/

Использование макросов даёт несколько преимуществ:

Это гарантирует корректную установку пакетов на мультибиблиотечных архитектурах.
Использование этих макросов вместо жёсткого указания каталога в spec-файле гарантирует, что ваш spec останется совместимым с установленной версией Python, даже если структура каталогов радикально изменится (например, если python3_sitelib переместится в %{_datadir}).

Пакеты, использующие Cython

Большое количество модулей расширения для Python (модулей Python, написанных на компилируемом языке, таком как C или C++) написаны с использованием языка и компилятора Cython.

Большинство таких пакетов содержит сгенерированные исходные коды C (или C++) в исходном архиве.

Ужесточая общую политику Fedora, пакеты НЕ ДОЛЖНЫ использовать предварительно сгенерированные исходные коды Cython. Они ДОЛЖНЫ быть удалены в %prep и сгенерированы заново во время сборки.

Любое исключение из этого правила следует рассматривать как начальную загрузку.

Файлы для включения

При упаковке модулей Python включаются несколько типов файлов:

*.py — исходные файлы, так как они используются при генерации трассировок.
*.pyc — байт-скомпилированные файлы.
- Python попытается создать их во время выполнения, если они не существуют, что приводит к ложным отказам SELinux AVC в журналах.
- Если системный администратор вызывает Python с -OO, они будут созданы без docstring. Это может нарушить работу некоторых программ.
*.egg-info или *.dist-info — файлы или каталоги. Если они создаются сборочными скриптами модуля, они должны быть включены в пакет, так как могут потребоваться другим приложениям и модулям во время выполнения.

Исходные файлы ДОЛЖНЫ быть включены в тот же пакет, что и байт-скомпилированные версии.

Упаковщикам НЕ СЛЕДУЕТ просто включать всё по маске в каталогах sitelib или sitearch. НЕ СЛЕДУЕТ использовать следующее:

%{python3_sitelib}/*
%{python3_sitearch}/*
%{python_sitelib}/*
%{python_sitearch}/*

И пакеты НЕ ДОЛЖНЫ включать каталог верхнего уровня __pycache__ (см. ниже).

Байт-компиляция

Python автоматически попытается байт-компилировать файлы при запуске, чтобы ускорить запуск в следующий раз. Эти файлы сохраняются в файлы с расширением .pyc (скомпилированный Python). Эти файлы будут находиться внутри каталога с именем __pycache__.

Файлы .pyc содержат байт-код, переносимый между ОС. Если вы не включите их в свои пакеты, Python попытается (и, как правило, потерпит неудачу) создать их, когда пользователь запустит программу. Если программу запустит системный администратор, файлы будут успешно записаны, что приведёт к появлению лишних .pyc-файлов, которые не будут удалены при удалении пакета. Чтобы предотвратить это, байт-скомпилированные файлы нужно скомпилировать и включить в раздел %files. Обычно байт-компиляция выполняется за вас скриптом brp-python-bytecompile. Этот скрипт запускается после обработки раздела %install spec-файла и байт-компилирует любые .py-файлы, которые он найдёт в %{python3_sitelib} или %{python3_sitearch} (эта перекомпиляция помещает правильные пути файловой системы в модули, иначе трассировки включали бы в себя %{buildroot}).

Вы должны включить .pyc-файлы в свой пакет. Если процесс сборки создаёт каталог __pycache__ в подкаталоге %{python3_sitearch} или %{python3_sitelib}, вы также должны включить все элементы в каталоге __pycache__. Вы НЕ ДОЛЖНЫ включать каталоги %{python3_sitearch}/__pycache__ или %{python3_sitelib}/__pycache__, поскольку они уже принадлежат пакету python3-libs.

Всё, что вам нужно сделать, — включить файлы в раздел %files (заменив %{python3_sitelib} на подходящий макрос для вашего пакета):

%files
%{python3_sitelib}/foo/

или, если код Python устанавливается напрямую в %{python3_sitelib}, используйте макрос %pycached, чтобы включить файлы кэша байт-кода:

%files
%pycached %{python3_sitelib}/foo.py

Это приблизительно разворачивается в

%files
%{python3_sitelib}/foo.py
%{python3_sitelib}/__pycache__/foo.cpython-%{python3_version_nodots}{,.opt-?}.pyc

Макрос %pycached поддерживает только Python 3.5+, поэтому для более старых версий Python (например, 3.4 в EPEL 6 или 7) вам нужно перечислять файлы вручную.

Если вам нужно использовать другие макросы вместе с макросом %pycached, такие как %exclude или %ghost, передайте другой макрос как часть аргумента %pycached. Например: %pycached %exclude /path/to/foo.py. Использование макросов в неправильном порядке применит %exclude только к первой записи, которую генерирует %pycached.

Ручная байт-компиляция

Дополнительные сведения о внутреннем устройстве байт-компиляции см. в приложении.

Пример Python spec-файла

Ниже приведён очень простой spec-файл для модуля Python.

python-example.spec

%global srcname example

Name:           python-%{srcname}
Version:        1.2.3
Release:        1%{?dist}
Summary:        Example python module

License:        MIT
URL:            https://pypi.python.org/pypi/example
Source:         %{pypi_source}

BuildArch:      noarch

%global _description %{expand:
A python module which provides a convenient example. This is the
rest of the description that provides more details.}

%description %_description

%package -n python3-%{srcname}
Summary:        %{summary}
BuildRequires:  python3-devel
BuildRequires:  python3-setuptools

%description -n python3-%{srcname} %_description

%prep
%autosetup -n %{srcname}-%{version}

%build
%py3_build

%install
%py3_install

%check
%{python3} setup.py test

# Note that there is no %%files section for the unversioned python module
%files -n python3-%{srcname}
%license COPYING
%doc README.rst
%{python3_sitelib}/%{srcname}-*.egg-info/
%{python3_sitelib}/%{srcname}/
%{_bindir}/sample-exec

Контрольный список для рецензента

Ниже кратко изложены правила, которые следует проверить рецензентам:

Обязательно: модули Python должны собираться из исходного кода. Нельзя просто поместить egg или whl из upstream в нужный каталог. (Подробности см. в правилах о предварительно собранных бинарных файлах).
Обязательно: модули Python не должны загружать какие-либо зависимости во время процесса сборки.
Обязательно: при сборке compat-пакета он должен устанавливаться с помощью easy_install -m, чтобы не конфликтовать с основным пакетом.
Обязательно: при сборке нескольких версий (для compat-пакета) один из пакетов должен содержать версию по умолчанию, которую можно использовать через "import MODULE" без предварительной настройки.
Следует: дополнительные provides python3-... следует выполнять через вызов %py_provides.
Следует: пакет, который используется другим пакетом через интерфейс egg, должен предоставлять egg info.

Want to help? Learn how to contribute to Fedora Docs ›