NoneBot CLI Standalone

Open mnixry opened this issue 3 years ago • 0 comments

OSPP 2022: NoneBot CLI Standalone Project Roadmap

这是开源之夏 - 暑期 2022 (OSPP 2022)项目的一部分:

随着 NoneBot2 Beta 版本的发布，脚手架功能存在一定的定位不明确、功能体验不佳。本项目旨在重新设计 nb-cli 功能框架，完善功能，优化用户体验。

主要要求

将nb-cli与nonebot2本体独立(standalone)，既nonebot2运行不需要nb-cli，nb-cli运行不依赖nonebot

现有问题

在操作逻辑上对虚拟环境不友好
- 原则上，nb-cli因为和nonebot2互相依赖，所以它需要被安装进入虚拟环境。
- 然而，它是创建项目的脚手架，而虚拟环境需要放置到项目目录，这就造成了操作逻辑上的冲突，使得nb-cli对大多数的使用虚拟环境进行管理的习惯很难融合。
用户定位不清晰
- 对能够接触到nb-cli的用户，一般分为两类：
  - 开发者：对于nonebot开发有一定了解，会自己撰写插件并进行调试
  - 部署用户：仅部署现有插件，搭建Bot为最终用户服务，一般不进行代码修改和撰写
- 目前来说，nb-cli更倾向于前者而非后者，然而对用户群体来说，后者比例会更大
- 这导致了现在nb-cli的安装过程较为复杂，而且会产生一些对后者来说难以用到的冗余文件

改进方案

功能需求

分离nb-cli和nonebot2，要求nb-cli可以通过pipx直装，作为一个纯命令行程序安装
为开发者和部署用户打造两套项目模板，后者需要最简化
将修改文件重载，既守护进程能力添加到nb-cli层面，而不限制于uvicorn专属，以规避一些跨平台问题
提供一定程度的扩展性，用户可以通过一些手段为nb-cli添加自定义的命令入口以完成统一化操作
- 主要用途可能是数据库迁移命令？
抽象插件安装等功能，为之后拓展（如Web UI等）做准备
可选：提供将某个Bot注册为系统服务的功能
- 比如Linux下使用systemctl的服务，以便进行后台运行
- 如果Python有现成的库就做，如果没有就不做，要跨平台搞这些太麻烦
可选：提供i18n功能，既检测命令行语言并选择使用
- 其实现阶段来讲肯定只有中文和英文，但是在代码里面直接写中文出命令行提示感觉不太对
- 所以还是做个i18n接口比较好，以后扩展起来应该也方便
可选：写点测试
- 感觉会很不好写，所以可选吧

实施方案

通过纯子进程调用对bot实例进行插件安装等操作
项目模板可以这样考虑：
- 删除pyprojcet.toml中和poetry有关的项目，让用户自行选择依赖管理方式
- 对于部署用户，创建一个只有pyproject.toml和.env文件的最小环境
- 关于bot.py的取代方案：在nonebot2本体中添加一个命令行调用入口，暂定名nonebot.loader
  - 调用形式大概是这种感觉：python -m nonebot.loader --adapter ~onebot:Adapter --plugin plugin --env-file .env
- 在部署模板时默认使用虚拟环境，因为部署用户原则上应该不需要到虚拟环境内进行操作，并且能够防止依赖污染
文件修改监视可以参考uvicorn现有的使用watchgod等的方案进行处理，同时也需要作为守护进程对子进程中Bot进程挂了的情况进行处理
- 这实际上允许了Bot的开发者通过终止Bot自身进程来实现重启Bot的功能
  - 这也是为提供Web UI等功能铺路的一种需要，也就是它能够允许我们在安装/卸载完毕插件以后重启Bot进程，既大家喜闻乐见的重载功能
    - 因为Python语言设计的原因，所以我们很难实现真正的热重载，只能以冷重载取而代之
扩展命令行的主要实现方式
- 我们目前的想法是让用户以特定命名方式注册script，然后nb-cli会扫描Bot运行环境中符合条件的scipt
  - 比如我们可以注册名字叫nb_cli-db的script，nb-cli在检测到之后就会多出来一个nb db指令，实际上就是nb_cli-db的alias
- 因为nb-cli和nb环境相互独立，所以不可能直接调用，只能通过命令行和扫文件类似的操作

参考方案

koishijs/koi 又是可以对标的东西，好欸！
vue-cli 这个我也不熟其实，但是ddl说有点像

大概就写到这里，还差一些参考链接和排版上的优化没有补充，~~有空再补~~

/cc @yanyongyu @felinae98

May 15 '22 15:05 mnixry