Rechercher

4.5. Emballage des RPMs de Python 3

download PDF

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.

4.5.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.

Important

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éfaut 3 ou 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 ici pello et, par conséquent, le name of the Source RPM (SRPM) est python-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 (ou python3.11-devel) et les projets pertinents nécessaires au logiciel spécifique que vous empaquetez, par exemple, python3-setuptools (ou python3.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éfixe python3.11- pour Python 3.11. Vous pouvez utiliser la macro %{python3_pkgversion}, qui évalue 3 pour la version 3.9 de Python par défaut, à moins que vous ne lui attribuiez une version explicite, par exemple 3.11 (voir note de bas de page 1).
5
Les macros %py3_build et %py3_install exécutent respectivement les commandes setup.py build et setup.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 pytest d'une manière adaptée à RPM.

4.5.2. Macros communes pour les RPMs Python 3

Dans un fichier SPEC, utilisez toujours les macros décrites dans le tableau suivant Macros for Python 3 RPMs plutôt que de coder en dur leurs valeurs. Vous pouvez redéfinir la version de Python 3 utilisée dans ces macros en définissant la macro python3_pkgversion au sommet de votre fichier SPEC (voir Section 4.5.1, « Description du fichier SPEC pour un paquetage Python »). Si vous définissez la macro python3_pkgversion, les valeurs des macros décrites dans le tableau suivant refléteront la version de Python 3 spécifiée.

Tableau 4.3. Macros pour les RPM de Python 3
MacroDéfinition normaleDescription

%{python3_pkgversion}

3

La version de Python utilisée par toutes les autres macros. Peut être redéfinie à 3.11 pour utiliser Python 3.11

%{python3}

/usr/bin/python3

L'interpréteur Python 3

%{python3_version}

3.9

La version majeure et mineure de l'interpréteur Python 3

%{python3_sitelib}

/usr/lib/python3.9/site-packages

L'emplacement où les modules Pure-Python sont installés

%{python3_sitearch}

/usr/lib64/python3.9/site-packages

Emplacement où sont installés les modules contenant des modules d'extension spécifiques à l'architecture

%py3_build

 

Exécute la commande setup.py build avec des arguments adaptés à un paquetage RPM

%py3_install

 

Exécute la commande setup.py install avec des arguments adaptés à un paquetage RPM

%{py3_shebang_flags}

s

L'ensemble des drapeaux par défaut pour la macro des directives de l'interpréteur Python, %py3_shebang_fix

%py3_shebang_fix

 

Modifie les directives de l'interpréteur Python en #! %{python3}, préserve les drapeaux existants (s'ils existent) et ajoute les drapeaux définis dans la macro %{py3_shebang_flags}

4.5.3. Utilisation des dépendances générées automatiquement pour les RPM Python

La procédure suivante décrit comment utiliser les dépendances générées automatiquement lors de l'empaquetage d'un projet Python sous forme de RPM.

Conditions préalables

Procédure

  1. Assurez-vous que l'un des répertoires suivants contenant les métadonnées fournies en amont est inclus dans le RPM résultant :

    • .dist-info
    • .egg-info

      Le processus de construction du RPM génère automatiquement des versions virtuelles de pythonX.Ydist à partir de ces répertoires, par exemple :

      python3.9dist(pello)

      Le générateur de dépendances Python lit ensuite les métadonnées en amont et génère des exigences d'exécution pour chaque paquet RPM en utilisant les pythonX.Ydist virtual provides générés. Par exemple, une balise d'exigences générée peut ressembler à ce qui suit :

      Requires: python3.9dist(requests)
  2. Inspecter les demandes générées.
  3. Pour supprimer certaines des exigences générées, utilisez l'une des approches suivantes :

    1. Modifier les métadonnées fournies en amont dans la section %prep du fichier SPEC.
    2. Utiliser le filtrage automatique des dépendances décrit dans la documentation en amont.
  4. Pour désactiver le générateur automatique de dépendances, incluez la macro %{?python_disable_dependency_generator} au-dessus de la déclaration Þscription du paquet principal.

Ressources supplémentaires

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.