Now that we know bits of how the Anaconda installer looks like and works internally, we can finally focus on the main topic of this guide, i.e. writing an addon for it. Let's take a top-down approach and start with the high-level aspects diving deeper and deeper. The only supported programming language for an Anaconda addon is Python with addon being a Python package. Thus it shouldn't be a surprise that an addon is actually a directory with an __init__.py and other source files and directories (subpackages) in it. And since one package name can be imported in Python only once, the top-level directory of an addon needs to have a unique name. The naming convention suggested for addons is to prefix the addon name with a reversed domain name as (it is common with e.g. D-Bus service names or Java packages) but using dashes instead of dots to separate subdomains so that the directory name is a valid identifier for a Python package. For example org_fedora_hello_world which is used by the Hello world addon from Section 6, “Writing an Anaconda addon”. As it has been mentioned in Section 1, “Introduction” everything should be supported in the kickstart first, then GUI and TUI pieces can come covering some (or all) configuration options from the kickstart part. As these three parts are more or less independent the Anaconda's addon API defines that they should be separate subpackages of the top-level addon package (i.e. subdirectories of the top-level directory) with the following names: ks, gui, tui and categories, with the ks being the only compulsory one. The gui and tui packages should then contain spokes subpackages. The categories package may contain module(s) defining categories if the addon needs to define one or more, but this is not recommended. ⁠^[4] All these packages have to contain at least one module with an arbitrary name defining classes inherited from one or more API defined classes. We will get to those classes in Section 6, “Writing an Anaconda addon”.