Replies: 6 comments 6 replies
-
|
首先,nonebot已经提供了事件的基类,但无法对具体情形的事件进行基类抽象,各平台的事件差距太大,难以做到满足功能的同时进行各平台的统一,这样做只会增大维护难度,抽象向各个平台事件进行妥协。就像OneBot V11,由于对各平台的不断妥协,修改事件标准,不得不停止了v11的更新,v12的最小抽象标准也由此诞生 目前的做法依然是提供平台重载,插件可以对不同平台做出不同的响应,这些都由插件自行编写。 另外,在商店发布的时候提供了标注平台适配的标签,不过大部分都没标 |
Beta Was this translation helpful? Give feedback.
-
单独回答一下这一部分, 这个是 |
Beta Was this translation helpful? Give feedback.
-
|
以下仅个人观点 根据功能实现角度,调用的类或方法最终需要从某一处导入或在当前功能内部实现。 显然不同平台都有独特的实现,故 NoneBot2 各平台的适配器最终也实现对应平台的可能实现。 更进一步的,插件开发者根据其目标平台,根据适配器的可用性来实现目标功能。
然后回到这个 import 失败的问题。。 说白了就是插件漏依赖,那这个是属于插件开发者在提交过程中所产生的问题。 这怎么会变成要求 NoneBot2 框架侧来提供平台约束呢?插件可能输出的东西也是五花八门的。 另外,对于商店插件的兼容性,在 Lancercmd/nonebot-store-test#1 进行了测试,可以一定程度上提供参考。 再次,敦促插件开发者尽快完成插件的依赖声明,优化插件商店环境。也希望插件开发者所提交的代码能够越来越高质量。 |
Beta Was this translation helpful? Give feedback.
-
|
感谢大佬们的回复。我又回头去翻了一下nonebot2的文档,发现是可以手动注册多个适配器的。现实生活中存在一个bot服务于多个平台的情况吗?这个我倒没有调研过...但这确实是可以让具体平台插件正常工作的一种办法,算是一种妥协吧。不知道我理解的对不对😂 我对插件的愿景是与具体平台(QQ、钉钉 etc.)无关,开发的时候只要导入具体平台的一个适配器就可以正常工作,看了 @mnixry 的回复,我想从某个程度上说,目标是一致的。 对于 @Lancercmd 的回复,就目前而言,我想能不能在进行插件审核的时候,要求开发者在文档中说明插件的运行环境,就比如适配器之类的,没有说明就不给过?
|
Beta Was this translation helpful? Give feedback.
-
|
有一个问题,适配器是每个平台一个还是每个平台可以有多个,用户可以自己选择呢? 如果是这样,只要做上层抽象就好了,留接口具体适配器去实现 应用发布的时候也可以多一个选项,选择插件适配的平台。(目前商店发布应用没有这个分类) |
Beta Was this translation helpful? Give feedback.
-
|
那个分类的问题,我的想法是在这里直接加一个比如多选框,让开发者选择平台(QQ、钉钉...),也就是必填项,而不是让开发者自己打tag(当然tag可以保留,加选项是为了更好将不同平台的bot区分),这样可能会好一些 |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
在导入他人插件的过程中会遇到以下错误
也就是
nonebot.adapters.cqhttp适配器找不到,我用的是onebot.V11适配器,这种情况不是一次两次了。在编写插件的过程中,对一些事件的处理,例如
GroupMessageEvent,需要从具体的适配器包中导入(QQ有QQ的实现,钉钉有钉钉的实现),这就导致了插件与某个适配器强耦合的问题,严重弱化了插件的通用性(而且挺多开发者并没有在文档中说明插件需要与哪个适配器共存)。所以考虑是否可以把事件之类的基类抽象化,让具体的适配器去继承实现?这样就可以实现插件与具体适配器间的解耦
Beta Was this translation helpful? Give feedback.
All reactions