5.7. Anaconda add-on structure
An Anaconda add-on is a Python package that contains a directory with an __init__.py and other source directories (subpackages). Because Python allows you to import each package name only once, specify a unique name for the package top-level directory. You can use an arbitrary name, because add-ons are loaded regardless of their name - the only requirement is that they must be placed in a specific directory.
The suggested naming convention for add-ons is similar to Java packages or D-Bus service names.
To make the directory name a unique identifier for a Python package, prefix the add-on name with the reversed domain name of your organization, by using underscores (_) instead of dots. For example, com_example_hello_world.
Make sure to create an __init__.py file in each directory. Directories missing this file are considered as invalid Python packages.
When writing an add-on, ensure the following:
-
Support for each interface (graphical interface and text interface) is available in a separate subpackage and these subpackages are named
guifor the graphical interface andtuifor the text-based interface. -
The
guiandtuipackages contain aspokessubpackage. [1] - Modules contained in the packages have an arbitrary name.
-
The
gui/andtui/directories contain Python modules with any name. - There is a service that performs the actual work of the addon. This service can be written in Python or any other language.
- The service implements support for D-Bus and Kickstart.
- The addon contains files that enable automatic startup of the service.
Following is a sample directory structure for an add-on which supports every interface (Kickstart, GUI and TUI):
com_example_hello_world
├─ gui
│ ├─ init.py
│ └─ spokes
│ └─ init.py
└─ tui
├─ init.py
└─ spokes
└─ init.py
Each package must contain at least one module with an arbitrary name defining the classes that are inherited from one or more classes defined in the API.
For all add-ons, follow Python’s PEP 8 and PEP 257 guidelines for docstring conventions. There is no consensus on the format of the actual content of docstrings in Anaconda; the only requirement is that they are human-readable. If you plan to use auto-generated documentation for your add-on, docstrings should follow the guidelines for the toolkit you use to accomplish this.
You can include a category subpackage if an add-on needs to define a new category, but this is not recommended.