我觉得适配器与插件不应该出现强耦合

[mgsky1]

在导入他人插件的过程中会遇到以下错误

...
  File "<frozen importlib._bootstrap_external>", line 783, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/Users/xxx/Desktop/Python/FG2.0/FG/venv/lib/python3.8/site-packages/nonebot_plugin_vf/__init__.py", line 4, in <module>
    from nonebot.adapters.cqhttp import Bot, PrivateMessageEvent, GroupMessageEvent, GROUP_OWNER, GROUP_ADMIN, PRIVATE
ModuleNotFoundError: No module named 'nonebot.adapters.cqhttp'

也就是nonebot.adapters.cqhttp适配器找不到，我用的是onebot.V11适配器，这种情况不是一次两次了。

在编写插件的过程中，对一些事件的处理，例如GroupMessageEvent，需要从具体的适配器包中导入（QQ有QQ的实现，钉钉有钉钉的实现），这就导致了插件与某个适配器强耦合的问题，严重弱化了插件的通用性（而且挺多开发者并没有在文档中说明插件需要与哪个适配器共存）。

所以考虑是否可以把事件之类的基类抽象化，让具体的适配器去继承实现？这样就可以实现插件与具体适配器间的解耦

[yanyongyu]

首先，nonebot已经提供了事件的基类，但无法对具体情形的事件进行基类抽象，各平台的事件差距太大，难以做到满足功能的同时进行各平台的统一，这样做只会增大维护难度，抽象向各个平台事件进行妥协。就像OneBot V11，由于对各平台的不断妥协，修改事件标准，不得不停止了v11的更新，v12的最小抽象标准也由此诞生

目前的做法依然是提供平台重载，插件可以对不同平台做出不同的响应，这些都由插件自行编写。

另外，在商店发布的时候提供了标注平台适配的标签，不过大部分都没标

[mnixry]

也就是nonebot.adapters.cqhttp适配器找不到，我用的是onebot.V11适配器，这种情况不是一次两次了。

单独回答一下这一部分, 这个是nonebot2 beta1的一个破坏性变更,和跨平台兼容性无关
如何迁移到beta1请看 #74

[mnixry]

另外, 感谢您对跨平台兼容这些问题提出您的疑惑. 在此处我希望分享一些对制作跨平台框架的时候需要实际面对的一些仍需解决的问题:

• 怎么样在完成跨平台事件兼容的同时, 保有每个平台独特的特性?
• 怎么样将各个平台不同的事件分发方式等统一起来?
• 即使在事件完成了跨平台统一, 那么平台独有的API调用又应该怎么处理?

还有最重要的一点:

• 怎么样在完成上述工作的同时, 保证程序代码可读性高, 易于理解和开发?

这些事情都是完成一款跨平台Bot SDK需要考虑的问题.

我承认, 我们在开发的时候对各个平台的兼容性确实有考虑不足, 到现在, 可能在框架内实现一款跨平台的事件/API兼容方案已经有点晚了
不过好在有了NoneBot2抽象了通信层和事件分发层的基础, 以及Beta1引入的依赖注入, 我相信这个工作可能在有朝一日被我们或者被社区, 以可选插件的形式完成
如果您有这样的意向, 也欢迎为建设NoneBot社区贡献自己的一份力量

---

同时, 在我认知的范围内, 也已经有很多框架在开发初期已经考虑了这些因素, 虽然它们可能并没有将我以上说的几点做到尽善尽美, 但是也值得一看:

• (TypeScript/JavaScript) koishijs/koishi - 现代、高效的跨平台聊天机器人框架
• (Python) GraiaProject/Avilla - The next-gen framework for IM development.
• and more...

[Lancercmd]

以下仅个人观点

根据功能实现角度，调用的类或方法最终需要从某一处导入或在当前功能内部实现。

显然不同平台都有独特的实现，故 NoneBot2 各平台的适配器最终也实现对应平台的可能实现。

更进一步的，插件开发者根据其目标平台，根据适配器的可用性来实现目标功能。

目标平台，没错，多数开发者在提交时都不会考虑所谓插件的跨平台表现。

但你需要理解，这是很正常的，为什么要适配一个别说 TA 自己甚至是没人用的平台呢。

更进一步的，在编写插件的过程中，import 行为也是很正常的。

然后回到这个 import 失败的问题。。

说白了就是插件漏依赖，那这个是属于插件开发者在提交过程中所产生的问题。

这怎么会变成要求 NoneBot2 框架侧来提供平台约束呢？插件可能输出的东西也是五花八门的。

另外，对于商店插件的兼容性，在 Lancercmd/nonebot-store-test#1 进行了测试，可以一定程度上提供参考。

再次，敦促插件开发者尽快完成插件的依赖声明，优化插件商店环境。也希望插件开发者所提交的代码能够越来越高质量。

[mgsky1]

感谢大佬们的回复。我又回头去翻了一下nonebot2的文档，发现是可以手动注册多个适配器的。现实生活中存在一个bot服务于多个平台的情况吗？这个我倒没有调研过...但这确实是可以让具体平台插件正常工作的一种办法，算是一种妥协吧。不知道我理解的对不对😂

我对插件的愿景是与具体平台(QQ、钉钉 etc.)无关，开发的时候只要导入具体平台的一个适配器就可以正常工作，看了 @mnixry 的回复，我想从某个程度上说，目标是一致的。

对于 @Lancercmd 的回复，就目前而言，我想能不能在进行插件审核的时候，要求开发者在文档中说明插件的运行环境，就比如适配器之类的，没有说明就不给过？

python中编写setyp.py中依赖的时候，有什么最佳实践吗？Java那边Maven已经提供了一套比较完善的依赖管理机制，依赖要先使用Maven导入才可以用。

[Lancercmd]

出于立场，我不能直接回答能或不能，但我可以与你更进一步地看你所遇到的问题。

我们依然以 nonebot_plugin_vf 为例，我们可以看到其 GitHub 仓库的最新提交状态几乎是空的，我们甚至无法检查其源代码。

那即使插件开发者在文档中字里行间地表示其以 QQ 作为目标平台，插件也未必能正常运行。

我们跳转到其历史提交，可以发现插件无论在 pyproject.toml 还是 setup.cfg 中，都没有声明任何依赖。

并且从你提问中所提供的代码片段可以看出，该提交和当前最新版本已经不符合了。

那即使插件开发者在文档中字里行间地表示其以 QQ 作为目标平台，插件也未必能在全新环境下正常运行。

那这不就像是在说文档和插件完全不对路啊，这文档有什么用啊？有用，插件在 当时 是能正常加载和使用的。

然后呢？以后呢？

这就是插件最初能通过审核并发布的原因？不完全正确，因为实际上插件审核工作的执行人一直都是暂缺的。

最简单的一个问题，如何审核呢？

插件不一定都是功能型插件，插件的实现可能五花八门，插件的仓库目录结构也可能五花八门。

@mnixry 已经在留言中提出了 NoneBot2 在 2.0.0-beta.1 版本存在破坏性改动，插件开发者理应对其发布的插件进行适配。

对于没有适配的插件，便可能在前述的 NoneBot2 商店速测报告中不通过。

你可能误解的一点是，其实对商店插件的统一测试是由我个人提出和自发进行的。

适配的方式也不仅限于适配 2.0.0-beta.1 插件还可以声明为 <=2.0.0-alpha16

而对框架侧的破坏性改动的适配效率，显然这完全是看所述的插件开发者了，但是有的插件开发者说不定都已经不玩了。

对于相当一部分插件的依赖声明缺失的问题，你可以理解为是插件开发者在钻空子。

多数插件开发者习惯性地假设了用户已经有一个能在目标平台上正常工作的项目。

所以你可以看到对 Adapter 依赖声明缺失的，对 nonebot2 依赖声明缺失的，
甚至是什么依赖都没声明的，哪怕是这依赖跟 NoneBot2 没什么关系。

我认为这个问题对 NoneBot2 有非常恶劣的影响，所以做出行动，对商店插件的依赖声明进行检查。

对于长期不进行处理的商店插件，此前也已经与 @mnixry @yanyongyu 等人进行了讨论。

所以你所提出的这个建议，也可以被上述项目参与人员所看见。

期待 TA 们可以为你提供更加清晰和更加可执行的解决方案回复。

要我自己说，那就是胁迫插件开发者进行依赖声明的修复。

[Lancercmd]

python中编写setyp.py中依赖的时候，有什么最佳实践吗？Java那边Maven已经提供了一套比较完善的依赖管理机制，依赖要先使用Maven导入才可以用。

我个人习惯于用 Poetry 进行项目的依赖管理和 PyPI 版本发布了。

[mgsky1]

有一个问题，适配器是每个平台一个还是每个平台可以有多个，用户可以自己选择呢？

如果是这样，只要做上层抽象就好了，留接口具体适配器去实现

应用发布的时候也可以多一个选项，选择插件适配的平台。（目前商店发布应用没有这个分类）

[mnixry]

有一个问题，适配器是每个平台一个还是每个平台可以有多个，用户可以自己选择呢？

原则上允许一个平台上有多个，比如QQ就有OneBot和mirai-api-http两种适配器
但是即使是相同平台的适配，它的抽象方法也可以大相径庭

如果是这样，只要做上层抽象就好了，留接口具体适配器去实现

跨平台抽象很难做，不是说做就能做出来的，原因我上面已经大概解释了一下

应用发布的时候也可以多一个选项，选择插件适配的平台。（目前商店发布应用没有这个分类）

有这个分类，你可以标记适配平台的标签，但是由于历史原因目前大多数插件还没标记

[mgsky1]

那个分类的问题，我的想法是在这里直接加一个比如多选框，让开发者选择平台（QQ、钉钉...），也就是必填项，而不是让开发者自己打tag（当然tag可以保留，加选项是为了更好将不同平台的bot区分），这样可能会好一些

[yanyongyu]

插件可能是与平台无关的，并不需要标注平台

[yanyongyu]

还有就是协议是会更新的，比如现在的QQ频道，api变动很大，之前的接口可能过几周就不能用了，那标注还是白标