5.7. Structure de l'extension Anaconda
Un add-on Anaconda est un paquetage Python qui contient un répertoire avec __init__.py et d'autres répertoires sources (sous-paquetages). Comme Python ne permet d'importer qu'une seule fois le nom de chaque paquetage, il convient de spécifier un nom unique pour le répertoire de premier niveau du paquetage. Vous pouvez utiliser un nom arbitraire, car les modules complémentaires sont chargés quel que soit leur nom - la seule exigence est qu'ils doivent être placés dans un répertoire spécifique.
La convention de dénomination suggérée pour les modules complémentaires est similaire aux paquets Java ou aux noms de services D-Bus.
Pour que le nom du répertoire soit un identifiant unique pour un paquetage Python, préfixez le nom du module d'extension par le nom de domaine inversé de votre organisation, en utilisant des traits de soulignement (_) au lieu de points. Par exemple, com_example_hello_world.
Veillez à créer un fichier __init__.py dans chaque répertoire. Les répertoires ne contenant pas ce fichier sont considérés comme des paquets Python non valides.
Lors de la rédaction d'un add-on, veillez aux points suivants :
-
La prise en charge de chaque interface (interface graphique et interface textuelle) est disponible dans un sous-paquet distinct, nommé
guipour l'interface graphique ettuipour l'interface textuelle. -
Les paquets
guiettuicontiennent un sous-paquetspokes. [1] - Les modules contenus dans les paquets ont un nom arbitraire.
-
Les répertoires
gui/ettui/contiennent des modules Python de n'importe quel nom. - Il existe un service qui effectue le travail réel de l'addon. Ce service peut être écrit en Python ou dans tout autre langage.
- Le service prend en charge D-Bus et Kickstart.
- L'addon contient des fichiers qui permettent le démarrage automatique du service.
Voici un exemple de structure de répertoire pour un module complémentaire qui prend en charge toutes les interfaces (Kickstart, GUI et TUI) :
Exemple 5.1. Exemple de structure de l'extension
com_example_hello_world ├─ gui │ ├─ init.py │ └─ spokes │ └─ init.py └─ tui ├─ init.py └─ spokes └─ init.py
Chaque paquetage doit contenir au moins un module avec un nom arbitraire définissant les classes héritées d'une ou plusieurs classes définies dans l'API.
Pour tous les modules complémentaires, suivez les directives PEP 8 et PEP 257 de Python pour les conventions des chaînes de documentation. Il n'y a pas de consensus sur le format du contenu réel des chaînes de documentation en Anaconda; la seule exigence est qu'elles soient lisibles par l'homme. Si vous prévoyez d'utiliser une documentation générée automatiquement pour votre module complémentaire, les chaînes de documentation doivent suivre les directives de la boîte à outils que vous utilisez pour ce faire.
Vous pouvez inclure un sous-paquetage de catégorie si un module complémentaire doit définir une nouvelle catégorie, mais cela n'est pas recommandé.
