Suivant: Modules Perl, Précédent: Paquets Emacs, Monter: Consignes d’empaquetage [Table des matières][Index]
Nous incluons actuellement Python 2 et Python 3, sous les noms de variables
Scheme python-2
et python
comme expliqué dans Numéros de version. Pour éviter la confusion et les problèmes de noms avec d’autres
langages de programmation, il semble désirable que le nom d’un paquet pour
un module Python contienne le mot python
.
Certains modules ne sont compatibles qu’avec une version de Python, d’autres
avec les deux. Si le paquet Toto ne compile qu’avec Python 3, on le nomme
python-toto
. S’il est compilé avec Python 2, on le nome
python2-toto
. Les paquets ne devraient être ajoutés que lorsqu’ils
sont nécessaires ; nous n’ajoutons pas les variantes Python 2 du paquet à
moins qu’on ne les utilise ensuite.
Si un projet contient déjà le mot python
, on l’enlève, par exemple le
module python-dateutil est packagé sous les noms python-dateutil
et
python2-dateutil
. Si le nom du projet commence par py
(p.
ex. pytz
), on le garde et on le préfixe comme décrit ci-dessus.
Remarque : Il y a actuellement deux systèmes de construction différents pour les paquets Python dans Guix : python-build-system et pyproject-build-system. Pendant longtemps, les paquets Python étaient construits à partir d’un fichier setup.py à la spécification informelle. Cela fonctionnait très bien, étant donné le succès de Python, mais il était difficile de construire des outils par dessus. En conséquence, de nombreuses alternatives ont émergé et la communauté a finalement retenu un standard formel pour spécifier les prérequis de construction. pyproject-build-system est l’implémentation de ce standard par Guix. Il est considéré comme « expérimental » dans le sens où il ne prend pas encore en charge les divers moteurs de construction de PEP-517, mais nous vous encourageons à l’essayer pour les nouveaux paquets Python et à rapporter tout problème que vous rencontreriez. Il finira par être rendu obsolète et fusionné dans python-build-system.
Les informations de dépendances pour les paquets Python se trouvent généralement dans l’arborescence des source du paquet, avec plus ou moins de précision : dans le fichier pyproject.toml, le fichier setup.py, dans requirements.txt ou dans tox.ini (ce dernier surtout pour les dépendances de test).
Votre mission, lorsque vous écrivez une recette pour un paquet Python, est
de faire correspondre ces dépendances au bon type « d’entrée »
(voir inputs). Bien que l’importeur pypi
fasse
du bon boulot (voir Invoquer guix import
), vous devriez vérifier la liste
suivant pour déterminer où va telle dépendance.
setuptools
et pip
installé par
défaut. Cela va changer, et nous vous encourageons à utiliser
python-toolchain
si vous voulez un environnement de construction pour
Python.
guix lint
vous avertira si setuptools
ou pip
sont
ajoutés en entrées natives car ils ne sont en général pas nécessaires.
propagated-inputs
. Elles sont typiquement définies dans le mot-clef
install_requires
dans setup.py ou dans le fichier
requirements.txt.
build-system.requires
dans pyproject.toml ou dans
le mot-clef setup_requires
de setup.py — ou les dépendances
seulement pour les tests — p. ex. ceux dans tests_require
— vont
dans native-inputs
. La raison est qu’ils n’ont pas besoin d’être
propagés car ils ne sont pas requis à l’exécution et dans le cas d’une
compilation croisée, c’est l’entrée « native » qu’il nous faut.
Les cadriciels de tests pytest
, mock
et nose
sont des
exemples. Bien sûr si l’un de ces paquets est aussi requis à l’exécution,
il doit aller dans propagated-inputs
.
inputs
, par exemple des programmes pour des bibliothèques C requises
pour construire des paquets Python avec des extensions C.
extras_require
),
c’est à vous de décider de les ajouter ou non, en fonction du ratio entre
utilité et complexité (voir guix size
).
Suivant: Modules Perl, Précédent: Paquets Emacs, Monter: Consignes d’empaquetage [Table des matières][Index]