CEP 2 - 向 conda 添加插件架构
| 标题 | 向 conda 添加插件架构 |
| 状态 | 已接受 |
| 作者 | Jannis Leidel <jleidel@anaconda.com> |
| 创建日期 | Jun 29, 2021 |
| 更新日期 | Jun 30, 2021 |
| 讨论 | https://github.com/conda/ceps/pull/1 |
| 实施 | (列在下方) |
动机
Conda 由许多移动部件组成，包括 `conda`/`conda-build` 项目，甚至第三方项目。它依赖于与各种技术和工作流程机制的松散耦合。
Conda 将从通用插件架构中获益，因为它将
- 涵盖目前服务不足的用例，
- 支持社区中更好的维护分配，
- 增加通过官方 API 扩展 conda 内部组件的能力
- 并降低 conda 生态系统中其他利益相关者贡献的门槛。
实施
-
集成 pluggy 或 HookMan 以在 conda 中托管一组钩子，并允许外部软件包提供插件，以补充 conda 附带的默认实现。
-
特别是对于性能关键的代码路径，插件架构将使开发创新解决方案成为可能，而无需冒险更改现有的稳定实现。
理由
Conda 的架构并非旨在通过官方插件 API 以编程方式扩展它。它可以从 Python 生态系统中其他已经使用插件多年的工具（例如 pytest、tox）中学习，这些工具拥有蓬勃发展且维护良好的生态系统。
与此同时，conda 作为一种用 Python 编写的工具，但在一个倾向于为工作使用最佳工具的生态系统中存在，这意味着插件架构最终应允许处理 Python 以外的编程语言和技术。
为 conda 项目的健康着想，也应该为社区提供为 conda 创建创新插件的手段，以迎合不断发展的科学界。第三方贡献者应使用官方 API，而不是不得不转向变通方法和包装器。
例如，CLI 已经可以通过 `PATH` 上遵循命名方案 `conda-([\w\-]+)$`（或 Windows 上的 `conda-([\w\-]+)\.(exe|bat)$`）的任何命令进行扩展。遗憾的是，这不足以实现与 conda 内部组件的低级别集成。
因此，为了更深入的集成功能，必须在 conda 中提供代码级别的插件钩子，例如，目前作为库 pycosat、pycryptosat 和 pysat 的静态映射实现的求解器功能。
其他可能有用处的示例领域（不属于此 CEP 的一部分）
-
shell 集成
-
依赖关系求解器后端
-
网络适配器
-
虚拟软件包发现
-
构建系统集成
-
语言支持（R、Julia 等）
向后兼容性
-
添加到 conda 的任何插件钩子都应默认为 conda 在接受其相关 CEP 时的最新主要版本中的工作方式。
-
未来对 conda 插件钩子默认值的更新应进行向后兼容性审查，并遵循明确的兼容性策略，例如仅在主要版本中更改。
参考
版权
所有 CEP 均明确采用 CC0 1.0 Universal。