The provided Python API to DNF is supposed to mainly allow writing the following two categories of programs:
- plugins to DNF which extend functionality of the system’s DNF installation.
- extension applications that embed DNF (by importing its Python modules) to perform specific package management tasks.
Please refer to the DNF Use Cases where you can find examples of API usage.
The API consists of exactly those elements described in this document, items not documented here can change release to release. Opening a bugzilla if certain needed functionality is not exposed is the right thing to do.
DNF follows the Semantic Versioning as defined at http://semver.org/.
This basically means that if your piece of software depends on e.g. DNF 1.1, the requirement can be specified as
1.1 <= dnf < 2. In other words, you can be sure that your software will be API-compatible with any later release of DNF until the next major version is issued. The same applies for the CLI compatibility.
Incompatible API changes are subject to our deprecation policy. Deprecated API items (classes, methods, etc.) are designated as such in the DNF Release Notes. The first release where support for such items can be dropped entirely must have, relative to the deprecating release, a higher major version number. DNF will log a warning when a deprecated item is used.
API Documentation Contents
- Common Provisions of the DNF API
Base—The centerpiece of DNF
- Repository Configuration
- Queries and Subjects
- Comps, or the Distribution Compose Metadata
- Plugin Interface
- Progress Reporting with Callbacks
- RPM Interface
- Command Line Interface Hooks
- Modularity Interface