Empaqueter des RPM Python

Récemment, je travaillais sur une tâche très spécifique dans le projet actuel que je suis
travaillant pour Red Hat, le RHEL Lightspeed
ShellAI, ce projet est
relativement nouveau mais nous voulions commencer à expédier des RPM de développement pour notre QE
amis pour commencer à jouer avec l'outil et à le tester dans leur pipeline.

Je connais bien l'emballage et les trucs généraux sur Python, mais mec, je dois le faire
je vous le dis, cette tâche d'emballage m'a pris deux jours entiers. Laisse-moi
guidez-vous très rapidement dans les détails de la tâche.

TLDR; tout s'est bien passé à la fin et voici le PR qui en résulte :
https://github.com/rhel-lightspeed/shellai/pull/4

Détails de la tâche

Le projet, ShellAI, est destiné à être livré sous RHEL 9 et le prochain
RHEL 10. En guise d'objectif bonus, nous aimerions le faire fonctionner également sur RHEL 8.

D'après la déclaration ci-dessus, si vous avez déjà travaillé avec RHEL auparavant, vous avez déjà
deviné que le défi sera la version des dépendances qui vit
dans RHEL.

• RHEL 8 a Python 3.6
• RHEL 9 a Python 3.9
• et enfin, RHEL 10 a Python 3.12

Nous aimerions également obtenir des versions de développement relativement fréquemment afin de
faire tester de nouvelles fonctionnalités au fur et à mesure que nous développons l'outil.

Pour la partie développement, nous aimerions utiliser
pdm pour gérer nos dépendances et
construit. Au fil des tâches, nous avons remarqué que le backend pdm n'est pas
livré dans les référentiels RHEL, nous avons donc opté pour la version setuptools par défaut
back-end.

Les cibles de notre système étant « relativement nouvelles », nous aimerions moderniser le
projet et assurez-vous que nous utilisons de nouveaux outils/structures et formats. Pour
ça, nous avons choisi de le faire avec un pyproject.toml, tel qu'il est généré via pdm init
lorsque nous avons démarré le projet.

Problèmes avec la construction du RPM

Au départ, notre idée était d'utiliser les fonctionnalités et le projet Python les plus récents
structure, telle que le fichier pyproject.toml au lieu de l'ancien setup.py.
Quand vous démarrez un nouveau projet, tout est cool et nouveau, vous êtes très excité
pour utiliser ce truc, le seul problème est :

• Ils sont très bons pour le processus de développement, mais pas pour l'emballage.

Au départ, lorsque j'ai commencé la tâche, je pensais que nous pourrions utiliser le nouveau RPM
macros pour construire le projet, puisque nous utilisons pyproject.toml et pdm pour
gérer les dépendances.

Pour cela, la documentation Fedora contient un article intéressant intitulé Python Packaging
Lignes directrices
où ils vont en détail. Alors que le guide couvre presque tous les sujets et cas
vous pourriez avoir besoin, même avec un exemple
fichier spécifique.

Notre cible principale étant RHEL, on pourrait imaginer que suivre tout
du guide fonctionnerait tel quel, n'est-ce pas ? Non. La raison en est que
versions livrées dans les référentiels RHEL. Même si ce sont les nouvelles macros
indiqué dans le guide peut fonctionner pendant la construction, vous ne pourrez pas générer
le RPM final dans les cibles suivantes :

• RHEL 8 vous enverra une erreur lors de %generate_buildrequires, comme la version python3-setuptools fournie dans cette version est très ancienne et fait je ne reconnais pas vraiment le nouveau format pyproject.toml.
• RHEL 9 pourra progresser dans la plupart des étapes, mais échouera %pyproject_wheel car il construira un package avec le nom UNKNOWN. Ce cela se produit parce que (encore une fois) les python3-setuptools livrés sous RHEL 9 sont vieux. Il ne reconnaît pas la plupart des métadonnées générées par le pyproject.toml specf.

La solution

Il fallait créer un héritage
setup.py
fichier afin de progresser dans les builds de la roue Python, et d'éviter les données
duplication entre le pyproject.toml et notre ancien fichier setup.py, nous
utilisé tomllib, à cause du
raisons suivantes :

• Le tomllib est disponible (via le packaging pypi et rpm) dans RHEL 8
• Après Python 3.11, tomllib a été intégré nativement dans la bibliothèque standard

Comme vous l'avez vu ci-dessus, nous avons utilisé tomllib pour charger le fichier pyproject.toml et
lisez les champs nécessaires et mettez simplement à jour notre ancien setup.py. De cette façon, nous
sommes capables de modifier pyproject.toml et chaque fois que nous pousserons une nouvelle version, nous le ferons
être également en mesure de conserver la cohérence dans notre ancien setup.py.

Concernant le specfile, nous avons dû revenir en arrière et utiliser ce que la documentation appelle
Emballage Python « ère 201x »
directives.
Essentiellement, nous utilisons la bonne vieille commande python setup.py build ...
(via des macros, évidemment) pour construire le projet.

Cette solution nous a permis de garder une cohérence entre les versions RHEL que nous souhaitons
pour prendre en charge et, en même temps, continuer à utiliser pdm et les nouvelles fonctionnalités brillantes
nous aimerions pour le développement.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!