随着 版本 22.11 的发布，conda 团队很高兴地宣布实施新的 conda 插件 API！此功能将使贡献者能够更自由地扩展 conda 的功能，而无需将代码合并到核心代码库中。
什么是插件？
“插件”是与特定软件兼容且可被其发现的定制或额外功能。它不是默认代码库的一部分，也不一定作为软件本身的默认部分进行分发。
具体而言，与 conda 相关的“插件”是指可能的新的功能，例如自定义子命令、开发环境集成（例如，shell）、依赖项解析器后端、编程语言支持等等！
conda 插件是如何实现的？
为了为 conda 实现插件系统，我们使用了 pluggy Python 框架（由其他项目使用，例如 pytest、tox 和 devpi）。由于 pluggy 的工作原理，开发人员可以通过定义“钩子”并在 conda 入口点命名空间下注册其自定义插件来轻松创建和使用 conda 插件。
如果您想详细了解 pluggy，请参阅其 文档。
conda 插件生态系统的优势
conda 插件 API 使许多优势和可能性成为可能，包括
-
供应商特定的扩展
-
对与打包相关的主题的支持（例如，虚拟软件包）
-
代码编辑器集成
-
conda 目前未涵盖的实验性功能
-
用于扩展默认实现功能的附加后端
-
…… 还有更多！
最重要的是，插件生态系统将使 conda 社区的贡献者能够开发和共享新功能，从而带来更多功能并专注于用户体验。
贡献 conda 插件
如前所述，pluggy 提供通过函数钩子扩展和修改 conda 行为的能力。这意味着任何人都可以开发插件，只要它可以通过使用 Python 软件包入口点进行发现。
在 22.11 版本中最初实施了三种类型的插件钩子
-
虚拟软件包：conda 用户现在可以开发插件来提供仅在运行时已知的属性（例如，操作系统信息）的版本标识
-
解析器：可以使用 conda_solvers 插件钩子使用额外的后端扩展替代解析器
-
子命令：提供使用 conda_subcommands 插件钩子扩展 conda 的能力
注意： conda 插件的发布方式尚未正式确定。无论最终选择哪种插件发布方式，都将在未来的 Conda 增强提案（CEP）中进行讨论和投票。
在插件开发过程中整合 CEP
目前已实施了 CEP 驱动的流程，以便 conda 维护人员能够更公开地为社区工作并与社区合作。在发展 conda 插件的代码基础设施和标准时，较大的架构更改（例如，当它们改变现状时）将伴随着正式的 CEP，并将包括以下信息
-
拟议的与插件相关的更改的动机、理由和目标
-
如何扩展和/或覆盖现有功能
-
实施范围和级别的定义
-
维护策略的选择
除了澄清每个新的提议的功能外，CEP 还鼓励来自社区的协作和讨论。每个 CEP 必须在拟议的工作被合并之前获得 指导委员会（或其代表）中大多数成员的批准，无论代码更改是谁贡献的。这样做是为了确保稳定性，考虑向后兼容性，并包括社区贡献。实际上，在实施之前将对提案进行彻底的审查和讨论。
如果您不确定是否需要为插件更改/添加创建 CEP，请在 conda GitHub 存储库中提交问题，conda 团队将指导您完成后续步骤。
结论
要详细了解新的 conda 插件生态系统，请查看 官方开发者文档，其中包括 API 参考，以及 插件模板 GitHub 存储库，其中包含有关如何开发自定义子命令的信息。
关于作者
Bianca Henderson 是 Anaconda 的软件工程师，负责 conda 和相关项目。她以前是 Red Hat 的开发人员，主要关注 AWX（Ansible Tower 的开源版本）的 API/后端部分。她最喜欢的编码内容是命令行界面和游戏。
