16.4.7 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 Foo ne compile qu’avec Ptyhon 3, on le nomme python-foo. S’il est compilé avec Python 2, on le nome python2-foo. 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.

16.4.7.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 setup.py, dans requirements.txt ou dans tox.ini.

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 2 avec setuptools et pip installé comme Python 3.4 par défaut. Ainsi, vous n’avez pas à spécifié ces entrées. guix lint vous avertira si vous faîtes cela.
• 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 le mot-clef setup_requires de setup.py — ou 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).