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.
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.
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.
