Modules Python (Manuel de référence de GNU Guix)

22.8.8 Modules Python

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 Python 2 sont en train d’être supprimés de la distribution. Merci de ne plus soumettre de nouveaux paquets Python 2.

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.

Spécifier les dépendances

22.8.8.1 Spécifier les dépendances

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.

Nous empaquetons Python avec 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.
Les dépendances Python requises à l’exécutions vont dans propagated-inputs. Elles sont typiquement définies dans le mot-clef install_requires dans setup.py ou dans le fichier requirements.txt.
Les paquets Python requis uniquement à la construction — p. ex. ceux listés dans 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.
Tout ce qui ne tombe pas dans les catégories précédentes va dans inputs, par exemple des programmes pour des bibliothèques C requises pour construire des paquets Python avec des extensions C.
Si un paquet Python a des dépendances facultatives (extras_require), c’est à vous de décider de les ajouter ou non, en fonction du ratio entre utilité et complexité (voir guix size).