另一种插件管理思路
Closed this issue · 2 comments
alex3236 commented
基于 chino 的观点整理,并根据 #94 优化部分思路。
插件库格式
meta/
master/ (Repo 1)
plugin_id.json (以插件 ID 命名的插件信息文件,或参考 #94 的每个插件单独文件夹的格式)
test/ (Repo 2)
plugin_id.json
docs/ (Github Action 生成,供人阅读)
master.md
test.md
api/ (Github Action 生成,管理器读取)
master.json
test.json
scripts/ (Github Action 脚本)
...
插件信息,即作者需要填写的内容内容
{
"Quick Backup Manager": {
"author": "Fallen_Breath",
"function":{
"en": "Backup/Restore plugin, with muti backup slot.",
"zh": "多槽位备份/回档插件。"
},
"storage": "https://github.com/Fallen-Breath/QuickBackupM"
},
"Another Plugin": {
// ...
}
}
API 信息,即插件管理器读到的,除了作者填写信息外的内容
{
"latest": "2.0", // 最新版本
"versions": {
"1.1": {
"file_path": "https://github.com/TISUnion/QuickBackupM/blob/873dc9fd1d873f62ec74c8c07a049c9bc558ce55/QuickBackupM.py",
"dependencies": { // 如果使用安装脚本则无需规定前置
"mcdreforged": ">=1.0.0",
"another_important_api": "*"
}
},
"1.0": {
"file_path": "https://github.com/TISUnion/QuickBackupM/blob/xxx/QuickBackupM.py", // 减少管理器的工作,可以直接给链接。给ID让管理器合成也不是不行
"dependencies": {
"an_important_api": "*"
}
}
// ...
}
作者仓库
/src: 源码文件夹
QuickBackupM.py
some_important_files
...
version.yml: 版本列表,详见后文“版本列表问题”
1.0.0: 873dc9fd1d873f62ec74c8c07a049c9bc558ce55 (Git commit ID)
1.5.1: ...
setup.py*: 如果使用安装脚本,则使用插件管理器给的 API 完成安装前置等工作,无需另外定义前置
def install():
# ...
data.json*: 如果不使用安装脚本,则需要单独列出前置等信息
README.md: 自述文件
...
个人观点
目前的基本架构可以确定了:插件库作者填写一次后无需再进行维护,而在自己的仓库按照特定格式维护。
Chino 的这个作者仓库方案其实比 #94 更优(对于机器),但对于作者的格式限制更多。
个人认为插件库支持多 repo、安装旧版本和检查更新还是有必要的。
版本列表问题
Chino 这样的版本记录方案如果让作者手写,有点过于繁琐。
让 Github Action 自动获取 Commit 列表并根据规定的格式自动获取和添加版本,这样就可以将旧版本纳入API里,并且不需要作者每次在多个文件中修改版本号。
比如:Commit 时需发布的版本使用版本号作为标题
另外,若 不 使用安装脚本,这个方法也可以方便地把旧版本前置信息纳入 API。
如果使用 Chino 这个手写的方案,则插件管理器在安装旧版本时需要手动在 Github 获取旧版本前置信息。
另外...
这个方案只对 Github 设计 :)
AnzhiZhang commented
虽然这个方案只针对GitHub设计,我经过了一些调整和优化,吸取了另一套方案的优点。整理后的方案在#100
Fallen-Breath commented
已于 MCDR 2.0 实现插件库规范
文档:https://mcdreforged.readthedocs.io/zh_CN/latest/plugin_dev/plugin_catalogue.html