Product SiteDocumentation Site

5. Anaconda Add-on Structure

An Anaconda add-on is a Python package containing a directory with an __init__.py and other source directories (subpackages) inside. Because Python allows importing each package name only once, the package top-level directory name must be unique. At the same time, the name can be arbitrary, 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 therefore similar to Java packages or D-Bus service names: prefix the add-on name with the reversed domain name of your organization, using underscores (_) instead of dots so that the directory name is a valid identifier for a Python package. An example add-on name following these suggestions would therefore be e.g. org_fedora_hello_world. This convention follows the recommended naming scheme for Python package and module names.

Important

Make sure to create an __init__.py file in each directory. Directories missing this file are not considered valid Python packages.
When writing an add-on, keep in mind that every function supported in the installer must be supported in Kickstart; GUI and TUI support is optional. Support for each interface (Kickstart, graphical interface and text interface) must be in a separate subpackage and these subpackages must be named ks for Kickstart, gui for the graphical interface and tui for the text-based interface. The gui and tui packages must also contain a spokes subpackage. [3]
Names of modules inside these packages are arbitrary; the ks/, gui/ and tui/ directories can contain Python modules with any name.
A sample directory structure for an add-on which supports every interface (Kickstart, GUI and TUI) will look similar to the following:

Example 1. Sample Add-on Structure

org_fedora_hello_world
├─ ks
│  └─ __init__.py
├─ 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 classes inherited from one or more classes defined in the API. This is further discussed in Section 6, “Writing an Anaconda add-on”.
All add-ons should 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 automatically generated documentation for your add-on, docstrings should follow the guidelines for the toolkit you use to accomplish this.


[3] The gui package may also contain a categories subpackage if the add-on needs to define a new category, but this is not recommended.