plugin-system

使用 Cargo 的 Rust 项目插件管理系统

这是什么？

插件系统可以部署在用户端软件中，包含一个“核心”组件和可选的“插件”，这些插件可以增加核心的功能。

传统上，当用户安装软件时，用户直接下载核心软件，然后下载可选的 .dll 插件文件，这些文件会动态链接到核心上。

一种改进的版本是核心软件提供了一个接口来下载 .dll 插件，从而避免了用户拖放文件的麻烦。

这个插件系统通过完全移除动态链接进一步改进了机制。当软件下载时，用户只需安装 Rust 工具链加上这个插件系统。然后用户编辑一个声明所需插件的文件。当软件启动时，会在名为 "stage" 的目录（$STAGE_DIR）中生成一个临时 crate，并在该子进程中自动运行 cargo run。这种方法有几个优点

• 所有二进制文件都是本地编译的，减少了恶意软件传播的可能性。
• 库是静态链接的，因此每个库只下载和编译一次（除非它们有不相容的版本）。
• 库是静态链接的，因此多个插件可以无缝交互。
• [在此处插入开源软件的所有优点]

但也有一些缺点

• 第一次或当用户更改插件列表时，重新编译需要很长时间。
• 分布式插件必须是开源的。
• [在此处插入所有针对开源软件的论点]

结构

• plugin-runtime-codegen：为 plugin-runtime 编写的复杂宏定义。
• plugin-runtime：在运行时由核心和插件加载。
• plugin-system：由包装 crate 加载。
• example/usage：示例包装 crate。
• example/core：示例核心。
• example/plugins/foo：示例插件，不是直接由 example/usage 使用，而是由 example/plugins/bar 依赖。
• example/plugins/bar：示例插件，依赖于 example/plugins/foo。

在测试示例时，设置 PS_LOCAL_RUNTIME 环境变量（可以是任何值），使其依赖于本仓库中的 plugin-runtime crate 而不是 crates.io 仓库中的版本。否则，可能会因为使用了多个版本的 plugin-runtime 导致编译失败。