With the release of version 22.11, the conda team is pleased to announce the implementation of a new conda plugin API! This feature will give contributors more freedom to extend conda’s functionality without needing to merge code into the core codebase.
What is a plugin?
A “plugin” is a customization or extra feature that is compatible with and discoverable by a particular piece of software. It is not part of the default codebase, nor is it necessarily distributed as a default part of the software itself.
Specifically in relation to conda, “plugins” refer to possible new functionalities such as custom subcommands, development environment integrations (e.g., shells), dependency solver backends, programming language support, and more!
How are conda plugins implemented?
For the implementation of a plugin system for conda, we used the pluggy Python framework (used by other projects such as pytest, tox, and devpi). Because of how pluggy works, developers can create and utilize conda plugins simply by defining “hooks” and registering their custom plugins under the conda entry point namespace.
If you’d like to learn more about pluggy, please refer to its documentation.
Benefits of a conda Plugin Ecosystem
A conda plugin API enables many benefits and possibilities, including:
-
Vendor-specific extensions
-
Support for packaging-related topics (e.g., virtual packages)
-
Code editor integrations
-
Experimental features that are not currently covered by conda
-
Additional backends to expand functionality of default implementations
-
… and much more!
Most importantly, a plugin ecosystem will allow contributors across the conda community to develop and share new features, thus bringing about more functionality and focus on the user experience.
Contributing a conda Plugin
As previously mentioned, pluggy provides the ability to extend and modify the behavior of conda via function hooking. This means that anyone can develop a plugin as long as it is discoverable with the use of Python package entry points.
Three types of plugin hooks have been initially implemented in the 22.11 release:
-
Virtual packages: conda users can now develop plugins that provide version identification for properties only known at runtime (e.g. OS information)
-
Solvers: Alternative solvers can be extended with additional backends with the conda_solvers plugin hook
-
Subcommands: Provides the ability to extend conda with the conda_subcommands plugin hook
Note: The way that conda plugins will be distributed has not been officially decided yet. Whichever way plugins will end up being distributed, this method will be discussed and voted on via a future Conda Enhancement Proposal (CEP).
Incorporating CEPs in the Plugin Development Process
A CEP-driven process is currently in place so that conda maintainers can work for and with the community more visibly. When evolving the code infrastructure and standards for conda plugins, larger architectural changes (e.g. when they change the status quo) will be accompanied by a formal CEP and will include the following information:
-
The motivation, rationale, and goals of the proposed plugin-related change
-
How to extend and/or override existing features
-
Definition of the scope and level of implementation
-
Selection of a maintenance strategy
In addition to clarifying each new proposed feature, CEPs also encourage collaboration and discussion from the community. Each CEP requires approval by the majority of the steering council (or their delegates) before the proposed work gets merged, independent of who is contributing the code changes. This is done to ensure stability, take backward compatibility into account, and include community contributions. In effect, proposals will be thoroughly reviewed and discussed before implementation.
When in doubt about whether or not a plugin change/addition will require a CEP, please file an issue in the conda GitHub repository and the conda team will guide you through next steps.
Conclusion
To learn more about the new conda plugin ecosystem, please check out the official developer documentation, which includes API references, as well as the plugin template GitHub repository for information on how to develop a custom subcommand.
About the Author
Bianca Henderson is a software engineer at Anaconda working on conda and related projects. She was previously a developer at Red Hat, mainly focusing on the API/backend portion of AWX (the open-source version of Ansible Tower). Her favorite things to code are command-line interfaces and games.
