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 gui for the graphical interface and tui for the text-based interface.
  • The gui and tui packages contain a spokes subpackage. [1]
  • Modules contained in the packages have an arbitrary name.
  • The gui/ and tui/ 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.



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

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat
맨 위로 이동