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 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.
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.
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.
propagated-inputs
. Elles sont typiquement définies dans le mot-clef
install_requires
dans setup.py ou dans le fichier
requirements.txt.
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
.
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]