CEP 4 - 实施初始 conda 插件机制
| 标题 | 实施初始 conda 插件机制 |
| 状态 | 已实施 |
| 作者 | Bianca Henderson <bhenderson@anaconda.com>, Jannis Leidel <jleidel@anaconda.com> |
| 创建于 | 2022 年 7 月 5 日 |
| 更新于 | 2022 年 8 月 22 日 |
| 讨论 | https://github.com/conda-incubator/ceps/pull/32 |
| 实施 |
|
摘要
为了启用与 conda 兼容且可被 conda 发现的自定义和额外功能（但不一定作为 conda 代码库的默认部分发布），我们希望实施官方的 conda 插件机制。
conda 中的插件机制将提供许多好处，包括（但不限于）覆盖服务不足的用例、通过官方 API 增加扩展 conda 内部构件的能力，以及降低来自 conda 社区和生态系统中其他利益相关者的贡献门槛。
关于添加此插件架构的初步提案已获得正式批准；当前的 CEP 将讨论实际实施插件机制的具体方式。
规范
conda 中的插件将通过利用 pluggy Python 框架来集成“钩子 + 入口点”结构。此实施可以分解为以下两个步骤
- 定义要注册的钩子
- 在
conda入口点命名空间下注册插件
钩子
以下是一个非常基本的插件“钩子”示例
my_plugin.py
import conda.plugins
@conda.plugins.register
def conda_subcommands():
...
通过 pyproject.toml 文件进行打包
以下是使用 pyproject.toml 文件配置 setuptools 的示例（请注意，如果定义了 pyproject.toml 文件，则 setup.py 文件是可选的）
pyproject.toml
[build-system]
requires = ["setuptools", "setuptools-scm"]
build-backend = "setuptools.build_meta"
[project]
name = "my-conda-plugin"
version = "1.0.0"
description = "My conda plugin"
requires-python = ">=3.7"
dependencies = ["conda"]
[project.entry-points."conda"]
my-conda-plugin = "my_plugin"
通过 setup.py 文件进行打包
以下是自定义插件函数的入口点命名空间示例，使用上面“钩子”部分中显示的插件钩子进行修饰
setup.py
from setuptools import setup
setup(
name="my-conda-plugin",
install_requires="conda",
entry_points={"conda": ["my-conda-plugin = my_plugin"]},
py_modules=["my_plugin"],
)
理由
这个新的 conda 插件 API 生态系统将带来许多好处和可能性，包括但不限于
- 自定义子命令
- 支持与打包相关的主题（例如，虚拟包）
- 开发环境集成（例如，shell）
- 备选依赖关系求解器后端
conda当前未涵盖的实验性功能
如前所述，官方插件生态系统还将使整个 conda 社区的贡献者能够开发和共享新功能，从而带来更多功能并关注用户体验。
向后兼容性
此新功能预计不会出现向后兼容性问题。
备选方案
以下列表列出了在拟议的 conda 插件实施中考虑使用的备选 Python 框架、库和包
最终，之所以决定使用 pluggy 作为此项目的理想框架，是因为它具有广泛的文档和相对简单的“钩子 + 入口点”配置。
实施
初始 conda 插件机制实施的拉取请求包括了大量的文档以及关于如何实施基本自定义子命令的教程。请将任何与实施相关的建议直接添加到此拉取请求中。
关于如何共享/分发这些插件的方法目前尚未决定，将在未来的 CEP 中进行讨论。
决议
这是一次标准的、非超时的投票。
本次投票已达到法定人数（10 + 0 = 10，至少占 16 的 60%）。
并且由于记录了 10 票“赞成”票和 0 票“反对”票，得分为 10/10，大于 15 的 60%，因此也已通过。
应注意的是，在拉取请求中记录了一个关于细微实施细节的更改请求，这些细节不会使之前的投票无效。作者已做出请求的更改。
参考
版权
所有 CEP 均明确采用 CC0 1.0 通用。