yohe (Sep 26 2024 at 03:09): yohe (Sep 26 2024 at 03:09):Hey, so our work has a critical dependency on wasmtime-py and we were hoping to get an overview of exactly what it has missing today with respective to say, something like JCO.
Our usecase is a library that is available in multiple language ecosystems like Js and Python. The library has a wasm based core authored in Rust and it works well enough but we'd love to move all the custom OS integration stuff to be based on top of wasi 0.2. wasmtime-py is not there yet for this it seems and I'm trying to see if there's something we can do about this.
So far, I have identified:
Anything other big missing pieces?
Alex Crichton (Sep 26 2024 at 03:23):Hello! So far wasmtime-py has mostly been a side project of me (and I'm by no means a Python programmer/expert) so in that sense I may be the only to answer here. In general the wasmtime-py bindings don't really have much in the way of support for components. Bindings for WASIp2 are a major part of that but in general resource support is entirely lacking. One of the major reasons for this is that wasmtime-py leans heavily on Wasmtime's C API which does not have component support at this time.
There's two major routes that can be taken for work like this for wasmtime-py to support components (assuming that's mostly what you're interested in):
Overall greatly expanding the component support of wasmtime-py is likely to be a sizable project to take on, and is generally why it hasn't happened already. Personally I've wanted to "one day" get around to the second route here, full support for components in the C API, but I haven't gotten to it yet (and don't have concrete plans to do so at this time).
If you're interested to help tackle this I'd be happy to chat in more depth about what might be necessary!
yohe (Sep 26 2024 at 04:15):Hey, thank you, that's very enlightening. I looked around the state of the C API with regards to component support and it does indeed seem on the tricky side.
It does seem like investing in the first route you laid out would be misguided seeing that it'd need to be re-written the moment the C API adds support for the component model. Though I'm not clear by what you mean by the C API obsoleting the need for the binding generation. Do you mean that the Val and get_func/call APIs would be good enough for this need?
I'm also unclear how in the second route would absolve wasmtime-py from having to implement wasip2. Is the aim to provide baseline support for the standard wasmtime-wasi impl in the shared library?
Alas, I'm at a loss how to continue. One path that appears to me is to add support to wasmtime-py.bindgen with all it needs to generate host bindings for the wasip2 APIs. Basically, route one but instead of having a full blown wasip2 impl in Python, we'd implement the specific APIs we're interested in downstream. This is only a marginal improvement over authoring custom host interfaces for FS stuff but it'd mean we avoid this cost on targets like JCO and wasmtime-rs.
Concretely, this means adding support for things like resource imports though I reckon that are a few other missing things. Any thoughts on this? I'll discuss all of this with the team I guess, thanks again.
Alex Crichton (Sep 28 2024 at 12:24):Though I'm not clear by what you mean by the C API obsoleting the need for the binding generation.
Right now the bindings generation that wasmtime-py has for components is along the lines of: given a single static component generate Python code, built on the core wasm support that wasmtime-py has, that represents the component. None of this is necessary though if wasmtime-py had native support for components because then loading a component would just look like "load this component" and then you'd interact with it as if it were an Instance.
There might still be some use in generating Python source with type annotations now that I think about it though. The major guts of the internals though would likely all go away and "just" rely on the native component support if it existed.
I'm also unclear how in the second route would absolve wasmtime-py from having to implement wasip2.
It's mostly that it would enable you as an embedder to instantiate components that import. Components which import wasip2 need to get that from somewhere, and currently in wasmtime-py the way it'd work is all of wasip2 would have to be implemented in Python. If wasmtime's component support were used then wasmtime's implementation of wasip2 could be used so no Python would be need in that regard.
I was discussing this with some folks in the BA Summit this week as well, and I think that the C API for components might be more tractable than I originally thought. If you're interested I'd be happy to chat more in-depth about what would go into that and help set you up for contribution if you'd like?
yohe (Sep 29 2024 at 00:05):Hey, thanks for more answers. I don't think the team/job would commit to the C API contribution path today but I'd personally like to contribute this in my own time. I haven't done a lot of C mind you but I'm knowledgeable in Rust and have done other manual memory stuff like Zig.
I've looked at the POC PRs on this item and it seems the biggest work is around the Val question and resource support. Where do you reckon I should start?
Alex Crichton (Sep 30 2024 at 14:29):I think Val is the main stickler at this time, so I'd recommend creating an API around that first. Basically a C API that can navigate a Rust-based Val without _too_ many inefficiencies I think is reasonable. For example it might make sense to have lots of "view" structs that are opaque in C and pointer-sized in Rust so you're passing around &Val or &Record or similar and that might be able to work out? (I'm not entirely sure though)
The dual of Val is Type which will also need access to inspect and cover as well.
Last updated: Dec 23 2024 at 13:07 UTC