Chapitre 3. Emballage des RPMs de Python 3
Vous pouvez installer des paquets Python sur votre système soit à partir du dépôt PyPI en amont en utilisant le programme d'installation pip, soit en utilisant le gestionnaire de paquets DNF. DNF utilise le format de paquetage RPM, qui offre plus de contrôle en aval sur le logiciel.
Le format d'empaquetage des paquets Python natifs est défini par les spécifications de la Python Packaging Authority (PyPA). La plupart des projets Python utilisent les utilitaires distutils ou setuptools pour l'empaquetage et définissent des informations sur les paquets dans le fichier setup.py. Cependant, les possibilités de créer des paquets Python natifs ont évolué au fil du temps. Pour plus d'informations sur les normes d'empaquetage émergentes, voir pyproject-rpm-macros.
Ce chapitre décrit comment empaqueter un projet Python qui utilise setup.py dans un paquetage RPM. Cette approche présente les avantages suivants par rapport aux paquets Python natifs :
-
Les dépendances sur les paquets Python et non-Python sont possibles et strictement appliquées par le gestionnaire de paquets
DNF. - Vous pouvez signer les paquets de manière cryptographique. La signature cryptographique permet de vérifier, d'intégrer et de tester le contenu des paquets RPM avec le reste du système d'exploitation.
- Vous pouvez exécuter des tests pendant le processus de construction.
3.1. Description du fichier SPEC pour un paquetage Python
Un fichier SPEC contient des instructions que l'utilitaire rpmbuild utilise pour construire un RPM. Les instructions sont incluses dans une série de sections. Un fichier SPEC se compose de deux parties principales dans lesquelles les sections sont définies :
- Préambule (contient une série de métadonnées utilisées dans le corps du texte)
- Corps (contient la partie principale des instructions)
Un fichier RPM SPEC pour les projets Python présente certaines spécificités par rapport aux fichiers RPM SPEC non-Python.
Le nom de tout paquetage RPM d'une bibliothèque Python doit toujours inclure le préfixe python3- ou python3.11-.
D'autres particularités sont présentées dans l'exemple de fichier SPEC suivant pour le paquet python3*-pello. Pour la description de ces spécificités, voir les notes sous l'exemple.
%global python3_pkgversion 3.11 1 Name: python-pello 2 Version: 1.0.2 Release: 1%{?dist} Summary: Example Python library License: MIT URL: https://github.com/fedora-python/Pello Source: %{url}/archive/v%{version}/Pello-%{version}.tar.gz BuildArch: noarch BuildRequires: python%{python3_pkgversion}-devel 3 # Build dependencies needed to be specified manually BuildRequires: python%{python3_pkgversion}-setuptools # Test dependencies needed to be specified manually # Also runtime dependencies need to be BuildRequired manually to run tests during build BuildRequires: python%{python3_pkgversion}-pytest >= 3 %global _description %{expand: Pello is an example package with an executable that prints Hello World! on the command line.} %description %_description %package -n python%{python3_pkgversion}-pello 4 Summary: %{summary} %description -n python%{python3_pkgversion}-pello %_description %prep %autosetup -p1 -n Pello-%{version} %build # The macro only supported projects with setup.py %py3_build 5 %install # The macro only supported projects with setup.py %py3_install %check 6 %{pytest} # Note that there is no %%files section for the unversioned python module %files -n python%{python3_pkgversion}-pello %doc README.md %license LICENSE.txt %{_bindir}/pello_greeting # The library files needed to be listed manually %{python3_sitelib}/pello/ # The metadata files needed to be listed manually %{python3_sitelib}/Pello-*.egg-info/
- 1
- En définissant la macro
python3_pkgversion, vous définissez la version de Python pour laquelle ce paquet sera construit. Pour construire pour la version 3.9 de Python, mettez la macro à sa valeur par défaut3ou supprimez entièrement la ligne. - 2
- Lorsque vous compilez un projet Python dans un RPM, ajoutez toujours le préfixe
python-au nom original du projet. Le nom original est icipelloet, par conséquent, le name of the Source RPM (SRPM) estpython-pello. - 3
- BuildRequires spécifie les paquets nécessaires pour construire et tester ce paquet. Dans BuildRequires, incluez toujours les éléments fournissant les outils nécessaires à la construction des paquets Python :
python3-devel(oupython3.11-devel) et les projets pertinents nécessaires au logiciel spécifique que vous empaquetez, par exemple,python3-setuptools(oupython3.11-setuptools) ou les dépendances d'exécution et de test nécessaires à l'exécution des tests dans la section \feck. - 4
- Lorsque vous choisissez un nom pour le RPM binaire (le paquet que les utilisateurs pourront installer), ajoutez un préfixe de version de Python. Utilisez le préfixe
python3-pour Python 3.9 par défaut ou le préfixepython3.11-pour Python 3.11. Vous pouvez utiliser la macro%{python3_pkgversion}, qui évalue3pour la version 3.9 de Python par défaut, à moins que vous ne lui attribuiez une version explicite, par exemple3.11(voir note de bas de page 1). - 5
- Les macros %py3_build et %py3_install exécutent respectivement les commandes
setup.py buildetsetup.py install, avec des arguments supplémentaires pour spécifier les emplacements d'installation, l'interpréteur à utiliser et d'autres détails. - 6
- La section \feck doit exécuter les tests du projet empaqueté. La commande exacte dépend du projet lui-même, mais il est possible d'utiliser la macro %pytest pour exécuter la commande
pytestd'une manière adaptée à RPM.
