Verpacken von Python-RPMs

Vor kurzem habe ich in dem aktuellen Projekt, an dem ich arbeite, an einer ganz bestimmten Aufgabe gearbeitet
arbeitet für Red Hat, das RHEL Lightspeed
ShellAI, dieses Projekt ist
relativ neu, aber wir wollten mit der Auslieferung von Entwicklungs-RPMs für unser QE beginnen
Freunde dazu auffordern, mit dem Tool herumzuspielen und es in ihrer Pipeline zu testen.

Ich kenne mich mit Verpackungen und allgemeinen Python-Sachen aus, aber Mann, ich muss es tun
Ich sage Ihnen, es hat mich zwei ganze Tage gekostet, diese Verpackungsaufgabe zu bewältigen. Lass mich
Führen Sie Sie sehr schnell durch die Details der Aufgabe.

TLDR; Am Ende hat alles geklappt und das ist die resultierende PR:
https://github.com/rhel-lightspeed/shellai/pull/4

Details zur Aufgabe

Das Projekt ShellAI soll unter RHEL 9 und den kommenden Versionen ausgeliefert werden
RHEL 10. Als Bonusziel möchten wir es auch auf RHEL 8 zum Laufen bringen.

Wenn Sie bereits zuvor mit RHEL gearbeitet haben, ist dies gemäß der obigen Aussage bereits der Fall
vermutet, dass die Herausforderung die Version der Abhängigkeiten sein wird, die lebt
in RHEL.

• RHEL 8 verfügt über Python 3.6
• RHEL 9 verfügt über Python 3.9
• und schließlich verfügt RHEL 10 über Python 3.12

Wir möchten auch relativ häufig Entwicklungs-Builds erhalten, um
Neue Funktionen testen, während wir das Tool entwickeln.

Für den Entwicklungsteil möchten wir
verwenden pdm zur Verwaltung unserer Abhängigkeiten und
baut. Als wir die Aufgaben durchgingen, stellten wir fest, dass das PDM-Backend nicht funktioniert
Wird in den RHEL-Repositorys ausgeliefert, daher haben wir uns für den Standard-Setuptools-Build entschieden
Backend.

Da unsere Systemziele „relativ neu“ sind, möchten wir das
modernisieren Projekt und stellen Sie sicher, dass wir neue Tools/Strukturen und Formate verwenden. Für
Dafür haben wir uns für ein pyproject.toml entschieden, da es über pdm init
generiert wird als wir das Projekt gestartet haben.

Probleme beim Erstellen des RPM

Ursprünglich bestand unsere Idee darin, die neuesten Python-Funktionen und -Projekte zu verwenden
Struktur, wie z. B. die Datei pyproject.toml anstelle der alten Datei setup.py.
Wenn man ein neues Projekt startet, ist alles cool und neu, man ist sehr aufgeregt
Um dieses Zeug zu verwenden, ist das einzige Problem:

• Sie eignen sich sehr gut für den Entwicklungsprozess, aber nicht für die Verpackung.

Als ich mit der Aufgabe begann, dachte ich zunächst, dass wir das neue RPM verwenden könnten
Makros zum Erstellen des Projekts, da wir pyproject.toml und pdm für
verwenden Abhängigkeiten verwalten.

Dazu gibt es in der Fedora-Dokumentation einen schönen Artikel mit dem Titel „Python Packaging“
Richtlinien
worauf sie im Detail eingehen. Dabei deckt der Leitfaden fast jedes Thema und jeden Fall ab
Sie benötigen möglicherweise sogar ein Beispiel
specfile.

Da unser Hauptziel RHEL ist, könnten wir uns vorstellen, dass wir alles verfolgen
aus dem Leitfaden würde so funktionieren, wie es ist, oder? Nein. Der Grund dafür liegt in der
Versionen, die in den RHEL-Repositorys ausgeliefert werden. Obwohl die neuen Makros
Wenn die in der Anleitung erwähnte Funktion möglicherweise während des Buildvorgangs funktioniert, können Sie sie nicht generieren
die Enddrehzahl in den folgenden Zielen:

• RHEL 8 wird Ihnen während %generate_buildrequires, as einen Fehler melden Die in dieser Version ausgelieferte Version von python3-setuptools ist super alt und das auch noch Erkenne das neue pyproject.toml-Format nicht wirklich.
• RHEL 9 kann die meisten Schritte durchlaufen, schlägt jedoch fehl %pyproject_wheel, da es ein Paket mit dem Namen UNKNOWN erstellt. Das Dies geschieht, weil (wieder) die unter RHEL 9 ausgelieferten Python3-Setuptools vorhanden sind alt. Die meisten Metadaten, die von generiert werden, werden nicht erkannt pyproject.toml specf.

Die Lösung

Wir mussten ein Vermächtnis schaffen
setup.py
Datei, um mit den Python-Wheel-Builds fortzufahren und Daten zu vermeiden
Duplizierung zwischen der pyproject.toml und unserer alten setup.py-Datei, wir
Ich habe tomllib verwendet, weil
folgende Gründe:

• Die Tomllib ist (über Pypi- und RPM-Paketierung) in RHEL 8 verfügbar
• Nach Python 3.11 wurde tomllib nativ in die Standardbibliothek gebündelt

Wie Sie oben gesehen haben, haben wir tomllib verwendet, um die Datei pyproject.toml zu laden und
Lesen Sie die erforderlichen Felder und aktualisieren Sie einfach unsere alte setup.py. Auf diese Weise
sind in der Lage, pyproject.toml zu ändern, und wann immer wir einen neuen Build pushen, werden wir das tun
in der Lage sein, die Konsistenz auch in unserem alten setup.py aufrechtzuerhalten.

Was die Spezifikationsdatei betrifft, mussten wir zurückgehen und das verwenden, was in der Dokumentation heißt
Python-Verpackung „201x-Ära“
Richtlinien.
Im Wesentlichen verwenden wir den guten alten Python-Befehl setup.py build ...
(natürlich durch Makros), um das Projekt zu erstellen.

Diese Lösung ermöglichte es uns, die Konsistenz aller gewünschten RHEL-Versionen aufrechtzuerhalten
um pdm und die glänzenden neuen Funktionen zu unterstützen und gleichzeitig weiter zu nutzen
Wir wünschen uns für die Entwicklung.

Das obige ist der detaillierte Inhalt vonVerpacken von Python-RPMs. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!