Paketbaurichtlinien für Python (201x-Ära)

In Fedora gibt es mehrere Python-Laufzeitumgebungen, eine für jede unterstützte Hauptversion von Python. Aktuell sind das eine für Python 3.x und eine für Python 2.7. Der Python-2-Stack wird jedoch aus Fedora entfernt und ist als veraltet gekennzeichnet. Die offizielle Unterstützung für den Python-2-Interpreter durch die Entwickler endet 2020. Software, die Python 3 unterstützt, muss für Python 3 paketiert werden. Software, die Python 2 verwendet, darf ohne Ausnahme von FESCo nicht neu in Fedora paketiert werden.

Richtlinien zur Pflege bereits bestehender Python2-Pakete finden Sie im Anhang.

In Fedora ist /usr/bin/python, sofern es installiert ist, ein symbolischer Link zu /usr/bin/python3. In früheren Versionen war es ein symbolischer Link zu /usr/bin/python2.

Pakete in Fedora DÜRFEN NICHT /usr/bin/python verwenden. Stattdessen MÜSSEN Pakete für Python 3 /usr/bin/python3 verwenden (auch wenn die Upstream-Version sowohl Python 2 als auch 3 unterstützt). Daher DÜRFEN /usr/bin/python (sowie /usr/bin/env python und ähnliche) NICHT in Shebang-Zeilen oder als Paketabhängigkeit verwendet werden. Jegliche Verwendung von nicht versionierten ausführbaren Python-Dateien in Shebang-Zeilen führt zu einem Baufehler. Diese Shebangs MÜSSEN korrigiert werden (z.B. durch Verwendung des Makros %py3_shebang_fix in der Spec-Datei). Falls die Prüfungen deaktiviert werden müssen, finden Sie weitere Informationen unter Shebang-Zeilen.

Alle Python-Laufzeitumgebungen bieten ein virtuelles „Provides“ für python(abi) = $MAJOR.$MINOR. Beispielsweise bietet das Python 3.7-Laufzeitpaket Folgendes:

Python-Module, die diese Laufzeitumgebungen verwenden, benötigen eine entsprechende „Requires“-Zeile in der Python-Laufzeitumgebung, mit der sie verwendet werden. Dies geschieht automatisch für Dateien unterhalb von /usr/lib[^/]*/python${PYVER}.

Analog zur Vorgehensweise bei regulären Paketen dürfen die Python-versionsspezifischen Teilpakete Ihres Pakets in einem Release-Zweig von Fedora NICHT entfernt werden.

Das Quellpaket einer Python-Bibliothek muss mit dem Präfix python- benannt werden. Ein gebautes Paket hingegen muss die Hauptversion von Python im Namen enthalten und verwendet daher das Präfix python3-. Dies wird durch Hinzufügen eines Teilpakets erreicht. Siehe Beispiel unten.

Diese Regel gilt nicht für Anwendungen.

Das Zeichen ` in Namen von erstellten Paketen (d.h. Nicht-SRPM-Paketen), die Verzeichnisse `.dist-info` oder `.egg-info` enthalten, ist für <<Python Extras>> reserviert und darf nicht anderweitig verwendet werden. Das Zeichen ` aktiviert die automatische Abhängigkeitsgenerierung für Extras. Ersetzen Sie alle `-Zeichen im Namen des Upstream-Pakets durch `-` oder lassen Sie sie am Namensanfang weg. Ausnahmsweise sind `-Zeichen am Ende des Namens zulässig.

Für Python 3 erstellte Pakete benötigen BuildRequires: python3-devel. Die meisten benötigen außerdem BuildRequires: python3-setuptools. Im Zweifelsfall prüfen Sie die Datei setup.py auf den Import von setuptools.

Pakete DÜRFEN KEINE Abhängigkeiten (weder zur Bau- noch zur Laufzeit) von Paketen mit dem versionierten Präfix python- aufweisen. Abhängigkeiten von Python-Paketen müssen stattdessen Namen verwenden, die mit python3- beginnen.

For any module foo intended to be used in Python 3 with import foo, the package that includes it should provide python3-foo. This is of course always the case if the subpackage is named python3-foo (as in the examples below). If the subpackage has some other name, then Provides: python3-foo should be added explicitly (via %py_provides python3-foo, see below).

When building a Python package, RPM looks for .dist-info and .egg-info files or directories in the %files sections of all packages. If one or more are found, RPM parses them to find the standardized name (i.e. dist name, name on PyPI) of the packaged software, and then automatically creates two Provides: tags in the following format:

The 3.Y is the Python version used (usually 3.6 and higher), and between the parentheses is the name of the software in a canonical format used by Python tools and services such as setuptools, pip and PyPI. The canonical name is obtained by switching the standardized name to lower case and converting all runs of non-alphanumeric characters to single “-” characters. Example: “The $$$ Tree” becomes “the-tree”.

When packaging software which is available from PyPI, you can make use of the %pypi_source macro. This macro accepts from zero to three arguments and evaluates to an appropriate URL for the source file on PyPI. The arguments are:

In den meisten Fällen ist es nicht notwendig, Argumente anzugeben.

The following macros are defined for you in all supported Fedora and EPEL releases:

During %install or when listing %files you can use the %{python3_sitearch} and %{python3_sitelib} macros to specify where the installed modules are to be found. For instance:

Die Verwendung der Makros bietet mehrere Vorteile:

A great amount of extension modules for Python (Python modules written in a compiled language such as C or C++) are written using the Cython language and compiler.

Majority of such packages contains the generated C (or C++) sources in the source tarball.

Tightening the general Fedora policy, packages MUST NOT use pre-generated Cython sources. They MUST be deleted in %prep and regenerated during the build.

Any exception to this rule should be considered a bootstrapping.

Beim Paketieren von Python-Modulen werden verschiedene Dateitypen einbezogen:

The source files MUST be included in the same package as the byte compiled versions.

Packagers SHOULD NOT simply glob everything under the sitelib or sitearch directories. The following SHOULD NOT be used:

And packages MUST NOT include the top-level __pycache__ directory (see below).

Python will automatically try to byte compile files when it runs in order to speed up startup the next time it is run. These files are saved in files with the extension of .pyc (compiled Python). These files will be located inside a directory named __pycache__.

The .pyc files contain byte code that is portable across OSes. If you do not include them in your packages, Python will try (and generally fail) to create them when the user runs the program. If the system administrator runs the program, then the files will be successfully written, causing stray .pyc files which will not be removed when the package is removed. To prevent that the byte compiled files need to be compiled and included in the %files section. Normally, byte compilation is done for you by the brp-python-bytecompile script. This script runs after the %install section of the spec file has been processed and byte compiles any .py files that it finds in %{python3_sitelib} or %{python3_sitearch} (this recompilation puts the proper filesystem paths into the modules otherwise tracebacks would include the %{buildroot} in them).

You must include the .pyc files in your package. If the build process creates a __pycache__ directory in a subdirectory of %{python3_sitearch} or %{python3_sitelib}, you must also include all items in the __pycache__ directory. You MUST NOT include the directories %{python3_sitearch}/__pycache__ or %{python3_sitelib}/__pycache__ because they are already owned by the python3-libs package.

All that you need to do is include the files in the %files section (replacing %{python3_sitelib} with the appropriate macro for your package):

or, if the Python code installs directly into %{python3_sitelib}, use the %pycached macro to include the bytecode cache files:

Das entspricht ungefähr

Nachfolgend finden Sie eine sehr einfache Spec-Datei für ein Python-Modul.

Nachfolgend sind die Richtlinien für die Reviewer kurz zusammengefasst: