I'm investigating how one might build a plugin system for a Rust CLI app using wasip2, and I have a few questions.
cargo-component works great to generate a rust project with a new empty wit file, and I can compile a wasip2 component. If I wanted to allow people to write plugins, would the correct way to do so is provide a versioned set of .wit files with all the necessary interface types and functions, and a helper crate for internal plugin functionality?
On the host end, it looks like the best way to do that would be to embed wasmtime. For this, it looks fairly straightforward, except for plugin detection and loading. It looks like if I have a wasip2 .wasm file, I can load it with Module::from_file()
. Is there a way to verify it provides the expected interface before I try to call functions from it?
Anything else y'all think I should know?
That all sounds reasonable to me, except you should use e.g. Component::from_file instead of Module::from_file
, since WASIp2 files are Wasm components rather than modules. You'll also want to make sure wasmtime-wasi
has been added to the component Linker
, and I recommend using wasmtime::bindgen!
to generate Rust host code from your plugin API WIT files. That generated code will take care of type checking for compatibility when you instantiate the component, as well as provided a statically-typed API you can use to call into plugins and provide host functionality to them.
You can find example code using multiple different plugin types at (patch still in review) https://gitlab.com/veloren/veloren/-/blob/9929b03cd4425bcc616b6f7c0d14fb571c8e0e3b/common/state/src/plugin/module.rs#L384 - the details are explained in https://veloren.net/blog/devblog-228/ (60% down)
Christof Petig said:
You can find example code using multiple different plugin types at (patch still in review) https://gitlab.com/veloren/veloren/-/blob/9929b03cd4425bcc616b6f7c0d14fb571c8e0e3b/common/state/src/plugin/module.rs#L384 - the details are explained in https://veloren.net/blog/devblog-228/ (60% down)
That's really awesome! With some help from Joel I've got a basic setup working. I've looked at plugin systems from Zed and Zellij, will have to add Veloren!
Christof Petig said:
You can find example code using multiple different plugin types at (patch still in review) https://gitlab.com/veloren/veloren/-/blob/9929b03cd4425bcc616b6f7c0d14fb571c8e0e3b/common/state/src/plugin/module.rs#L384 - the details are explained in https://veloren.net/blog/devblog-228/ (60% down)
I'm curious why the patch is still in review, could you link to the merge request? It looks like Veloren has a plugin system already based on wasi-preview1, is that correct?
The plugin system is already based on p2, but this one is introducing different types of plugins and a more complex example. Sorry, I didn't realize that this link didn't contain the MR number... (searching)
And it didn't get approved because of vacation, the initial feed back was positive.
It is? Like I read these docs: https://book.veloren.net/contributors/modders/writing-a-plugin.html
and it seems to just be compiling to wasip1
https://gitlab.com/veloren/veloren/-/merge_requests/4351
Updating the docs is next on my list. :face_palm:
Background here is I just wrote a blog post about it comparing prior art: https://benw.is/posts/plugins-with-rust-and-wasi
It's just a draft right now, but I did make assumptions
But the old plugin architecture was broken for some time and this patch has years of history, you can find more information in veloren's discord (plugins channel) .
So the wasip2 system is released? Guess I'll have to dig into the codebase
PS: if you look for WIT plugins without wasm I have much more information to share, but this is not related to veloren.
benwis said:
So the wasip2 system is released? Guess I'll have to dig into the codebase
I really recommend to not look at the state before this MR.
This is what I had written btw:
Veloren, an open source action RPG, currently has a plugin system based on WASI preview 1, with a system based on WASIp2 proposed here.
The WASIp2 system is interesting in that it appears the intention is to have developers use the WIT files to develop against, instead of hiding them and using a rust crate. All in all, this implementation looks closest to my desired approach. Looking forward to seeing it in production soon.
Christof Petig said:
PS: if you look for WIT plugins without wasm I have much more information to share, but this is not related to veloren.
Admittedly I have no idea how this would work
benwis said:
Christof Petig said:
PS: if you look for WIT plugins without wasm I have much more information to share, but this is not related to veloren.
Admittedly I have no idea how this would work
See the links in this
Thread
Last updated: Nov 22 2024 at 17:03 UTC