随着 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 存储库中提交一个 issue，conda 团队将指导您完成后续步骤。
结论
要了解有关新的 conda 插件生态系统的更多信息，请查看官方开发者文档，其中包含 API 参考，以及插件模板 GitHub 存储库，以获取有关如何开发自定义子命令的信息。
关于作者
Bianca Henderson 是 Anaconda 的一名软件工程师，致力于 conda 及相关项目。她之前是 Red Hat 的一名开发人员，主要专注于 AWX（Ansible Tower 的开源版本）的 API/后端部分。她最喜欢编写命令行界面和游戏。
