Richtlinien für die Python-Paketierung

Jedes Paket, das Python (zur Laufzeit und/oder während des Bauvorgangs) verwendet und/oder Python-Module installiert, MUSS eine Bauabhängigkeit von python3-devel haben, selbst wenn Python während des Bauprozesses nicht tatsächlich aufgerufen wird. Ein solches Paket muss eine der folgenden Optionen in seiner .spec-Datei verwenden:

Eine transitive Bauabhängigkeit von python3-devel allein reicht nicht aus. Wenn das Paket einen alternativen Python-Interpreter anstelle von python3 verwendet (z.B. pypy, jython, python2.7), KANN es stattdessen das entsprechende *-devel-Paket benötigen.

Das Paket *-devel bindet relevante RPM-Makros ein. Es ermöglicht außerdem automatisierte oder manuelle Prüfungen: Beispielsweise nutzen Python-Entwickler diese Abhängigkeit, um Pakete aufzulisten, die Python in irgendeiner Weise verwenden und von geplanten Änderungen betroffen sein könnten.

Die folgenden Makros MÜSSEN verwendet werden, wo immer es möglich ist.

Die in Klammern stehenden Expansionen dienen lediglich als Referenz bzw. Beispiele.

Die Makros sind in allen unterstützten Fedora- und EPEL-Versionen für Sie definiert.

Im restlichen Teil dieses Dokuments werden diese Makros zusammen mit %{_bindir}(/usr/bin/) anstelle der rohen Pfadnamen verwendet.

Fedora zielt primär auf CPython ab, die Referenzimplementierung der Programmiersprache Python. Wir verwenden „Python“ im Allgemeinen synonym mit CPython.

Alternative Implementierungen wie pypy sind verfügbar, bieten aber derzeit keine umfassenden Werkzeuge und Richtlinien für die Paketierung. Bei der Verwendung dieser Implementierungen gibt es keine festen Regeln (abgesehen von den allgemeinen Fedora-Paketbaurichtlinien). Bitte versuchen Sie jedoch, den Sinn dieser Richtlinien zu beachten. Im Zweifelsfall konsultieren Sie die Python SIG.

Fedora-Pakete DÜRFEN NICHT von anderen Versionen des CPython-Interpreters als der aktuellen Version python3 abhängen.

In Fedora sind Python-Bibliotheken für eine einzige Python-Version, genannt python3, paketiert. In Fedora 32 entspricht python3 beispielsweise Python 3.8.

Früher gab es mehrere Python-Stacks, z.B. python3.7 und python2.7, die gleichzeitig auf demselben Rechner installiert werden konnten. Das ist auch bei einigen Projekten der Fall, die auf Fedora aufbauen, wie RHEL, EPEL und CentOS. Fedora könnte in Zukunft wieder parallel installierbare Stacks einführen (z. B. wenn ein Wechsel zu einer neuen Python-Version eine Übergangsphase erfordert oder wenn sich genügend interessierte Betreuer finden).

Fedora enthält zwar alternative Interpreterversionen, z.B. python2.7 oder python3.5, diese sind jedoch nur für Entwickler gedacht, die Upstream-Code testen müssen. Fehlerbehebungen und Sicherheitsaktualisierungen für diese Interpreter decken ausschließlich diesen Anwendungsfall ab. Pakete wie pip oder tox, die das Einrichten isolierter Umgebungen und die Installation von Drittanbieterpaketen darin ermöglichen, KÖNNEN diese Interpreter als Ausnahme von der obigen Regel verwenden, sofern dies mit den Betreuern des jeweiligen Python-Interpreters abgestimmt ist.

Die meisten dieser Namen sind maschinenlesbare, Groß- und Kleinschreibung berücksichtigende Identifikatoren, aber der Projektname hat eine menschenfreundliche Semantik: Er ist von Groß- oder Kleinschreibung unabhängig und behandelt bestimmte Zeichenketten (wie ._-) speziell. Für die automatisierte Verwendung muss er in ein kanonisches Format normalisiert werden, das von Python-Werkzeugen und Diensten wie setuptools, pip und PyPI verwendet wird. Der kanonische Name des Projekts Django lautet beispielsweise django (in Kleinbuchstaben). Diese Normalisierung ist in PEP 503 definiert und wird von dem Makro %{py_dist_name} für die Fedora-Paketierung implementiert. Der kanonische Name wird ermittelt, indem der Projektname in Kleinbuchstaben umgewandelt und alle nicht-alphanumerischen Zeichen durch einzelne Bindestriche („-“) ersetzt werden. Beispiel: „The $$$ Tree“ wird zu „the-tree“.

An anderer Stelle in diesem Text bezieht sich die Metavariable DISTNAME auf die kanonische Form des Projektnamens.

Beachten Sie, dass an einigen Stellen der ursprüngliche, nicht normalisierte Projektname verwendet werden muss. Beispielsweise benötigen die Makros %pypi_source` und %autosetup den Namen Django und nicht django.

Das Zeichen + in Namen von erstellten (d.h. nicht SRPM-)Paketen, die die Verzeichnisse .dist-info oder .egg-info enthalten, ist für Extras reserviert und DARF NICHT für andere Zwecke verwendet werden.

Ausnahmsweise können +-Zeichen *am Ende solcher Namen vorkommen.

Das Zeichen + löst den automatischen Abhängigkeitsgenerator für Extras aus.

Ersetzen Sie alle +-Zeichen im Upstream-Namen durch -. Lassen Sie die +-Zeichen am Anfang des Namens weg. Erwägen Sie, Provides für den ursprünglichen Namen mit +-Zeichen hinzuzufügen, um das Paket für Benutzer leichter auffindbar zu machen.

Ein gebautes (d.h. nicht SRPM-)Paket für eine Python-Bibliothek MUSS mit dem Präfix python3- benannt werden. Ein Quellpaket, das hauptsächlich eine Python-Bibliothek enthält, MUSS mit dem Präfix python- benannt werden.

Der Name des Fedora-Pakets SOLLTE den [Kanonischen Projektnamen] enthalten. Wenn möglich, SOLLTE der Projektname mit dem Namen des importierbaren Hauptmoduls übereinstimmen, jedoch in Kleinbuchstaben und mit Unterstrichen (_) anstelle von Bindestrichen (-).

Wenn der Name des importierbaren Moduls und der Projektname nicht übereinstimmen, kommt es häufig zu Verwirrung bei den Nutzern. In diesem Fall SOLLTEN die Paketierer sicherstellen, dass die Upstream-Entwickler über das Problem informiert sind und (insbesondere bei neuen Paketen, bei denen eine Umbenennung möglich ist) eine Umbenennung anstreben. Die Python SIG steht Ihnen dabei gerne zur Seite.

Eine Python-Bibliothek ist ein Paket, das in Python importiert werden soll, beispielsweise mit import requests. Werkzeuge wie Ansible oder IDLE, deren Code zwar importierbar ist, aber nicht primär für den Import aus anderer Software gedacht ist, gelten in diesem Sinne nicht als Bibliotheken. Daher trifft dieser Abschnitt nicht auf sie zu. (Allgemeine Hinweise finden Sie in den allgemeinen Richtlinien für Bibliotheken und Anwendungen.)

Der Name einer Fedora-Komponente (Quellpaket) für eine Bibliothek sollte aus dem kanonischen Projektnamen gebildet werden, dem python- vorangestellt wird, sofern dieser nicht bereits mit python- beginnt. Dies kann zu Konflikten führen (z. B. zwischen bugzilla und python-bugzilla). In diesem Fall sollte sichergestellt werden, dass die Upstream-Entwickler über die potenziell verwirrende Namensgebung informiert sind und nach bestem Wissen und Gewissen entschieden wird.

Pakete, die primär Anwendungen, Dienste oder ausführbare Dateien jeglicher Art bereitstellen, SOLLTEN gemäß den allgemeinen Fedora-Benennungsrichtlinien benannt werden (z.B. ansible).

Erwägen Sie, eine virtuelles „Provides“ gemäß [Library naming] oben hinzuzufügen (z. B. python3-PROJEKTNAME), falls dies den Benutzern helfen würde, das Paket zu finden.

Pakete MÜSSEN die Quelldatei (*.py) UND den Bytecode-Cache (*.pyc) für jedes importierbare reine Python-Modul enthalten. Die Quelldateien MÜSSEN im selben Paket wie der Bytecode-Cache enthalten sein.

Skripte, die nicht importierbar sind (typischerweise solche in %{_bindir} oder %{_libexecdir}), SOLLTEN NICHT byte-kompiliert werden.

Die Cache-Dateien befinden sich in einem __pycache__-Verzeichnis und haben ein interpreterabhängiges Suffix wie .cpython-39.pyc.

Der Cache ist für die Ausführung der Software nicht erforderlich. Falls er jedoch nicht gefunden wird, versucht Python, ihn beim Import eines Moduls zu erstellen. Gelingt dies, wird die Datei nicht von RPM verfolgt und verbleibt nach der Deinstallation auf dem System. Schlägt die Erstellung fehl, können Benutzer fälschlicherweise SELinux-AVC-Fehler in den Protokollen erhalten.

Normalerweise übernimmt das BRP-Skript brp-python-bytecompile die Byte-Kompilierung (Erstellung der Cache-Dateien). Dieses Skript wird automatisch ausgeführt, nachdem der Abschnitt %install der Spec-Datei durchlaufen wurde. Es byte-kompiliert alle .py-Dateien, die es in %{python3_sitelib} oder %{python3_sitearch} findet.

Sie müssen diese Dateien in Ihr Paket einbinden (d.h. im Abschnitt %files).

Falls der Code sich in einem Unterverzeichnis befindet (importierbares Paket), binden Sie das ganze Verzeichnis ein:

Das Hinzufügen eines abschließenden Schrägstrichs ist für Verzeichnisse empfehlenswert.

Dies ist jedoch nicht für Module der obersten Ebene anwendbar (z.B. %{python3_sitelib}), da sowohl %{python3_sitelib} als auch %{python3_sitelib}/__pycache__/ zu Python selbst gehören. Hier kann das Makro %pycached Abhilfe schaffen. Es expandiert zur angegebenen *.py-Quelldatei und den zugehörigen Cache-Dateien. Zum Beispiel:

expandiert ungefähr zu:

Jedes Python-Paket MUSS Paketverteilungsmetadaten enthalten, die den PyPA-Spezifikationen entsprechen (insbesondere Recording installed projects).

Die Metadaten SOLLTEN im selben Teilpaket wie das importierbare Hauptmodul enthalten sein, sofern ein solches existiert.

Dies gilt sowohl für Bibliotheken (z.B. python-requests) als auch für Werkzeuge (z.B. ansible).

Wenn Software in mehrere Teilpakete aufgeteilt wird, ist es in Ordnung, die Metadaten nur in einem einzigen RPM-Paket auszuliefern. In diesem Fall sollten Sie mit dem Upstream-Projekt zusammenarbeiten, um dieses ebenfalls aufzuteilen.

Die Metadaten liegen in Form eines .dist-info-Verzeichnisses vor, das in %{python3_sitelib} oder %{python3_sitearch} installiert ist und Informationen enthält, die Werkzeuge wie importlib.metadata zur Untersuchung installierter Bibliotheken verwenden.

Ein Projekt namens MyLib mit dem importierbaren Paket mylib könnte beispielsweise wie folgt paketiert werden:

Beachten Sie, dass einige ältere Werkzeuge Metadaten stattdessen in einem .egg-info-Verzeichnis oder sogar in einer einzelnen Datei speichern. Dies geschieht nicht, wenn Sie das Makro %pyproject_wheel verwenden. Falls Ihr Paket ein Bausystem verwendet, das ein .egg-info-Verzeichnis oder eine .egg-info-Datei erzeugt, wenden Sie sich bitte an die Python SIG.

Ausnahmsweise KANN die Python-Standardbibliothek auch ohne diese Metadaten ausgeliefert werden.

Pakete DÜRFEN KEINE gemeinsam genutzten Verzeichnisse besitzen, die Python selbst gehören, wie z.B. die Verzeichnisse der obersten Ebene __pycache__(%{python3_sitelib}/__pycache__, %{python3_sitearch}/__pycache__).

Ähnlich wie bei der allgemeinen Regel sollten Paketierer NICHT einfach alles unter einem gemeinsamen Verzeichnis globben.

Zusätzlich zu allgemeinen Listen sollte Folgendes NICHT in %files verwendet werden:

Diese Regel dient als Kontrollmechanismus gegen häufige Fehler, die sonst schwer zu erkennen wären. Sie schränkt jedoch einige Automatisierungsmöglichkeiten ein.

Die häufigsten Fehler, die diese Regel verhindert, sind:

Für jedes Modul, das in Python 3 mit import MODULNAME verwendet werden soll, SOLLTE das Paket, das es enthält, python3-MODULNAME bereitstellen, wobei Unterstriche (_) durch Bindestriche (-) ersetzt werden.

Dies ist natürlich immer der Fall, wenn das Paket den Namen python3-MODULNAME trägt. Hat das Teilpaket einen anderen Namen, fügen Sie %py_provides python3-MODULNAME explizit hinzu. Weitere Informationen zu %py_provides finden Sie im folgenden Abschnitt.

Für jedes FOO sollte ein Paket, das python3-FOO bereitstellt, %py_provides oder einen automatischen Generator verwenden, um auch python-FOO und python3.X-FOO bereitzustellen, wobei X die Nebenversion des Interpreters ist.

Das „Provides“ SOLLTE NICHT manuell hinzugefügt werden: Wenn kein Generator oder Makro verwendet wird, fügen Sie die „Provides“ für python-FOO / python3.X-FOO überhaupt nicht hinzu.

Dies geschieht automatisch für Paketnamen durch einen Generator. Falls unbedingt erforderlich, kann der Generator deaktiviert werden, indem das [Makro %__pythonname_provides] undefiniert wird.

Für „Provides“, die keine Paketnamen sind, oder (aus technischen Gründen) für Pakete ohne Dateien, funktioniert der Generator nicht. In diesen Fällen liefert der folgende Aufruf „Provides“ für python3-FOO, python-FOO und python3.X-FOO:

Die Verwendung des Generators oder Makros ist wichtig, da sich die konkrete Form des „Provides“ in Zukunft ändern kann.

Jedes Python-Paket MUSS python3dist(DISTNAME) und python3.Xdist(DISTNAME) bereitstellen, wobei X die Nebenversion des Interpreters und DISTNAME der [Canonical Project Name] ist, der den [Dist-info metadata] entspricht. python3-django würde beispielsweise python3dist(django) und python3.9dist(django) bereitstellen.

Dies wird automatisch aus den Dist-Info-Metadaten generiert. Die Bereitstellung SOLLTE NICHT manuell hinzugefügt werden: Falls die Generierung fehlschlägt, MÜSSEN die Metadaten korrigiert werden.

Diese Provides werden für automatisch generierte Requires verwendet.

Falls unbedingt erforderlich, kann der automatische Generator deaktiviert werden, indem das Makro %{?__pythondist_provides} undefiniert wird. Besprechen Sie Ihren Anwendungsfall gegebenenfalls mit der Python SIG.

Wie bereits oben erwähnt, MUSS jedes Python-Paket explizit python3-devel in „BuildRequires“ haben.

Pakete DÜRFEN KEINE Abhängigkeiten (weder zur Bau- noch zur Laufzeit) mit dem unversionierten Präfix python- haben, wenn stattdessen die entsprechende Abhängigkeit python3- verwendet werden kann.

Pakete SOLLTEN KEINE expliziten Abhängigkeiten (weder zur Bau- noch zur Laufzeit) mit einem Minor-Versionspräfix wie python3.8- oder python3.8dist( haben. Solche Abhängigkeiten SOLLTEN stattdessen automatisch generiert oder ein Makro verwendet werden, um die Version zu ermitteln.

Pakete SOLLTEN KEINE explizite Laufzeitabhängigkeit von python3 haben.

Anstatt von python3 abzuhängen, haben Pakete eine automatische Abhängigkeit von`python(abi) = 3.X, wenn sie Dateien nach%{python3_sitelib}` oder`%{python3_sitearch}` installieren, oder sie haben eine automatische Abhängigkeit von`/usr/bin/python3, wenn sie ausführbare Python-Skripte enthalten, oder sie haben eineautomatische Abhängigkeit vonlibpython3.X.so.1.0()`, wenn sie Python einbetten.

Diese Regeln tragen zu einem reibungslosen Aktualisierungsprozess bei, wenn python3 in neuen Versionen von Fedora aktualisiert wird.

Pakete MÜSSEN den automatischen Python-Laufzeitabhängigkeitsgenerator verwenden.

Pakete SOLLTEN nach Möglichkeit den optionalen Bauabhängigkeitsgenerator verwenden.

Der Paketierer MUSS die generierten Abhängigkeiten auf Korrektheit prüfen. Alle Abhängigkeiten MÜSSEN in der Zielversion von Fedora auflösbar sein.

Alle notwendigen Änderungen MÜSSEN durch Patches oder Modifizierung des Quellcodes (z.B. mit sed) erfolgen, anstatt den Generator zu deaktivieren. Die resultierende Änderung SOLLTE dem Upstream-Projekt angeboten werden. Ausnahmsweise DARF Filterung für temporäre Workarounds und Bootstrapping verwendet werden.

Abhängigkeiten, die bereits von den Generatoren abgedeckt werden, SOLLTEN NICHT in der .spec-Datei wiederholt werden. (Wenn der Generator beispielsweise eine requests-Abhängigkeit findet, ist Requires: python3-requests überflüssig.)

Die automatisch generierten Abhängigkeiten haben die Form python3.Xdist(DISTNAME), gegebenenfalls ergänzt durch Versionsabhängigkeiten oder kombiniert mit Rich-Abhängigkeiten. Alle Suffixe .0 werden aus den Versionsnummern entfernt, um dem Verhalten von Python-Tools zu entsprechen. (PEP 440 legt fest, dass X.Y und X.Y.0 als gleichwertig behandelt werden.)

Beachten Sie, dass die Generatoren nur Python-Pakete abdecken. Andere Abhängigkeiten, oft C-Bibliotheken wie openssl-devel, müssen manuell in der .spec-Datei angegeben werden.

Wo die Abhängigkeiten im Quellcode spezifiziert werden, hängt vom jeweiligen Bausystem und den Präferenzen des Projekts ab. Übliche Speicherorte sind pyproject.toml, setup.py, setup.cfg und config.toml.

Siehe den Tests-Abschnitt.

Python-Extras sind eine Möglichkeit für Python-Projekte, zu deklarieren, dass zusätzliche Abhängigkeiten für zusätzliche Funktionalität erforderlich sind.

Beispielsweise hat requests mehrere Standardabhängigkeiten (z.B. urllib3). Es deklariert aber auch ein Extra namens requests[security], das zusätzliche Abhängigkeiten auflistet (z.B. cryptography). Im Gegensatz zu RPM-Teilpaketen können Extras nur zusätzliche Abhängigkeiten, aber keine zusätzlichen Dateien angeben. Das Hauptpaket funktioniert auch ohne die optionale Abhängigkeit, allerdings mit eingeschränkter Funktionalität.

Python-Werkzeuge behandeln Extras als virtuelle Pakete. Wenn ein Benutzer beispielsweise pip install 'requests[security]' ausführt oder ein Projekt installiert, das von requests[security] abhängt, werden sowohl requests als auch cryptography installiert.

In Fedora werden Extras üblicherweise von Paketen ohne Dateien bereitgestellt. Anstelle von eckigen Klammern verwenden Fedora-Paketnamen konventionell das Zeichen + (das in RPM-Paketnamen zulässiig ist, jedoch nicht in kanonischen Python-Projektnamen oder in Extras-Bezeichnern).

Shebang-Zeilen zum Aufruf von Python MÜSSEN %{python3} als Interpreter verwenden.

Die Shebang-Zeilen zum Aufruf von Python SOLLTEN #!%{python3} -%{py3_shebang_flags} lauten und KÖNNEN zusätzliche Flags enthalten.

Falls (einige) der Standardflags aus the %{py3_shebang_flags} macro nicht erwünscht sind, SOLLTEN Pakete das Makro explizit neu definieren, um sie zu entfernen, indem sie das entsprechende %{_py3_shebang_...}-Makro undefinieren.

Die Verwendung von #!%{python3} (#!/usr/bin/python3) anstelle von z. B. #!/usr/bin/env python stellt sicher, dass der systemweite Python-Interpreter zum Ausführen des Codes verwendet wird, selbst wenn der Benutzer $PATH ändert (z.B. durch Aktivieren einer virtuellen Umgebung).

Standardmäßig wird -%{py3_shebang_flags} zu -sP expandiert (oder einfach zu -s bei Python-Versionen unter 3.11 und Fedora Linux-Versionen vor 37).

Das Flag -s, gespeichert in dem Makro %{_py3_shebang_s}, bedeutet, dass das Benutzerverzeichnis nicht zu sys.path hinzugefügt werden soll. Dadurch wird sichergestellt, dass die Python-Pakete des Benutzers (z.B. installiert mit pip install --user oder einfach im aktuellen Verzeichnis abgelegt) nicht mit der per RPM installierten Software in Konflikt geraten. Manchmal ist dies jedoch erwünscht, beispielsweise bei Plugins.

Das Flag -P, gespeichert in dem Makro %{_py3_shebang_P}, bedeutet, dass das Skriptverzeichnis nicht zu sys.path hinzugefügt werden soll. Manchmal ist es jedoch erwünscht, das Skriptverzeichnis zu sys.path hinzuzufügen, z.B. bei ausführbaren Python-Skripten, die in einem benutzerdefinierten Verzeichnis installiert sind und sich gegenseitig importieren.

Das Entfernen der unerwünschten Flags aus dem Makro %{py3_shebang_flags}, anstatt das Makro gar nicht zu verwenden, stellt sicher, dass bestehende oder zukünftige Automatisierungen das Flag nicht hinzufügen.

Das Makro %pyproject_install ändert automatisch alle Python-Shebangs in %{buildroot}%{_bindir}/* so, dass sie %{python3} verwenden, und fügt den Inhalt des Makros %{py3_shebang_flags}zu den bestehenden Flags hinzu. Wenn Sie dieses Makro nicht verwenden oder einen Shebang in einem anderen Verzeichnis ändern müssen, können Sie das Makro %py3_shebang_fix wie folgt verwenden:

Jedes ausführbare WERKZEUG, für das die aktuelle Python-Version relevant ist, SOLLTE auch mit python3 -m WERKZEUG aufrufbar sein.

Falls die Software diese Funktionalität nicht bietet, SOLLTEN die Paketierer die Upstream-Entwickler bitten, sie hinzuzufügen.

Dies gilt für Werkzeuge, die die aktuelle Python-Umgebung verändern (z.B. durch Installieren oder Abfragen von Paketen), Python zur Konfiguration verwenden oder Plugins mit Python ausführen. Es gilt nicht für Werkzeuge wie GIMP oder Bash, die Plugins in mehreren Sprachen unterstützen und/oder andere Möglichkeiten zur Angabe des Interpreters bieten.

Beispielsweise kann pip als python3 -m pip aufgerufen werden.

Dies ermöglicht es Benutzern, die zum Ausführen der Software verwendete Python-Version präzise anzugeben. Diese Konvention funktioniert in verschiedenen Umgebungen, in denen $PATH möglicherweise nicht immer konsistent gesetzt oder Skripte nicht einheitlich installiert werden.

Falls eine Testsuite im Upstream-Projekt existiert, SOLLTE diese im Abschnitt %check ausgeführt werden. Ist dies mit zumutbarem Aufwand nicht möglich, MUSS zumindest ein einfacher Funktionstest (z.B. das Importieren des paketierten Moduls) im Abschnitt %check durchgeführt werden.

Sie DÜRFEN einzelne fehlgeschlagene Tests ausschließen. Sie DÜRFEN NICHT die gesamte Testsuite deaktivieren oder deren Ergebnis ignorieren, um einen Baufehler zu beheben.

Ausnahmsweise DÜRFEN Sie Tests mit einer entsprechenden %if-Bedingung deaktivieren (z.B. mit bcond beim Bootstrapping.

Die meisten Fehler in Python treten zur Laufzeit auf, daher sind Tests extrem wichtig, um Probleme aufzuspüren, insbesondere wenn Massen-Rebuilds erforderlich sind.

Häufige Gründe für das Überspringen von Tests in %check sind angeforderter Netzwerkzugriff, Abhängigkeiten, die nicht in Fedora paketiert sind, und/oder spezielle Hardware oder Ressourcen.

In diesen Fällen können Sie the`%pyproject_check_import oder the%py3_check_import` macro verwenden, um zu testen, ob installierte Module importierbar sind.

Ein Teil des Python-Paketierungsökosystems, der noch immer nicht standardisiert ist, ist die Angabe von Testabhängigkeiten (und Entwicklungsabhängigkeiten im Allgemeinen).

Eine gute und gängige Methode für Upstream-Projekte, Testabhängigkeiten anzugeben, ist die Verwendung vonextra wie [test], [testing] oder [dev]. In diesem Fall könnten die Anweisungen des Upstream-Projekts zur Installation der Testabhängigkeiten wie $ pip install -e.[test] aussehen.

Eine weitere Möglichkeit, Testabhängigkeiten anzugeben, ist die Verwendung einer dedizierten Abhängigkeitsgruppe (PEP 735).

Projekte, die tox verwenden, geben Testabhängigkeiten üblicherweise in einem tox-spezifischen Format an, einem requires-Schlüssel in der Konfiguration.

Diese drei Formen werden durch das Makro%pyproject_buildrequires verarbeitet.

Falls die Upstream-Version keine der beiden Formen verwendet, listen Sie die Testabhängigkeiten manuell als BuildRequires in der spec-Datei auf, zum Beispiel:

Falls dies erforderlich ist, sollten Sie die Upstream-Entwickler bitten, ein zusätzliches [test] oder eine test-Abhängigkeitsgruppe hinzuzufügen.

In %check SOLLTEN Pakete KEINE „Linter“ ausführen: Code-Style-Checker,Testabdeckungs-Checker und andere Tools, die die Codequalität anstatt derFunktionalität überprüfen.

Werkzeuge wie black, pylint, flake8 oder mypy sind oft „meinungsbehaftet“ und ihre „Meinungen“ ändern sich so häufig, dass sie in Fedora lästig sind, da der Linter nicht an eine bestimmte Version gebunden ist. Darüber hinaus benötigen einige dieser Werkzeuge lange Zeit, um sich an neue Python-Versionen anzupassen, was frühe Tests mit Alpha- und Beta-Versionen von Python verhindert. Und sie sind schlichtweg unnötig: Falsch formatierter Code ist nicht wichtig genug, als dass der Fedora-Paketbetreuer die Entwickler deswegen kontaktieren müsste. Ein solches Problem einen Paketbaustein zerstören zu lassen, ist völlig unangemessen.

Linter sind in Upstream-CI durchaus sinnvoll. Aber nicht in Fedora.

Falls ein Linter verwendet wird, deaktivieren Sie ihn und entfernen Sie die Abhängigkeit davon. Falls dies nicht einfach ist, sprechen Sie mit den Upstream-Entwicklern darüber, wie dies vereinfacht werden kann (z.B. durch eine Konfigurationsoption oder eine separate tox-Umgebung).

Bei Paketen, die solche Linter enthalten, verwenden Sie diese zur Laufzeit oder erweitern Sie sie.Normalerweise müssen Sie den Linter in %check ausführen. Führen Sie ihn aus, um die Funktionalität zu testen, nicht die Codequalität der paketierten Software.

Die „pyproject-Makros“ sind besonders nützlich für das Paketieren von Python-Projekten, die die in PEP 518 und PEP 517 definierte Datei pyproject.toml verwenden. Diese Datei spezifiziert die Bauabhängigkeiten des Pakets (einschließlich des Bausystems, z.B. setuptools, flit oder poetry).

Falls pyproject.toml nicht gefunden wird, greifen die Makros automatisch auf setuptools mit der Konfiguration in setup.cfg/setup.py zurück.

Eine vollständige Anleitung und Erläuterung der Makros finden Sie im README der Makro-Dokumentation.

Die folgenden Makros stehen für Fälle zur Verfügung, in denen die automatische Generierung deaktiviert ist. Sie können auch nützlich sein, um Dateien an ungewöhnlichen Speicherorten zu verarbeiten, an denen die Generatoren nicht suchen.

Die folgenden Makros können für spezielle Anwendungsfälle neu definiert werden.

Beim Vergleich von Python-Versionen (z.B. um zu fragen: Ist %{python3_version} größer als 3.8?) ist die Verwendung von naiven Ausdrücken wie %if %{python3_version} > 3.8 oder %if "%{python3_version}" > "3.8" nicht möglich, da der Vergleich alphabetisch auf Zeichenketten erfolgt. Daher ist zwar "3.10" < "3.8" korrekt (was jedoch nicht gewünscht ist).

Versionsliterale lassen sich explizit vergleichen, indem Sie das Präfix v verwenden, ähnlich den String-Präfixen in Python:

Die folgenden Makros können die Python-spezifische Automatisierung deaktivieren.

Falls nötig, sollten Sie sich an die Python SIG wenden.

Die folgenden Makros sind veraltet. Informationen zur Verwendung einiger dieser Makros finden Sie in den Python-Paketbaurichtlinien der 201x-Ära.