Support WIT resource types #197
Comments
|
Thanks for the report! Resources aren't implemented at all yet and will probably need a good chunk of work to implement them, but luckily I think componentize-py has probably also done a good deal of the hard work so lifting most of the implementation from there would probably work. |
|
My team is investigating dedicating some resources to get this implemented (thankfully we have a Python guy), and just curious if we could get a quick outline of the work required to support this? I see the related PR to componetize-py that you mentioned, would the work be similar to whats present there? |
|
That'd be great! I'm happy to be around to answer questions, so don't hesitate to reach out either here or on Zulip or on email. Another resource I'd recommend is the implementation of resources in jco. The compilation model of jco is the same as wasmtime-py where it takes an input component and spits out glue using a core wasm API. I believe that this file will be of interest and you should find the high-level organization of jco and wasmtime-py to look pretty similar. For example wasmtime-py will probably want an almost exact copy of this function and probably others. Handling of |
|
Hi @alexcrichton @landonxjames , is ti possible to share the status of this feature? We would like to use |
|
Hello! No status on this yet, I don't believe anyone's working on it. |
|
Hi, I'm looking into what's needed to implement resources in If we use the WIT file at the top of this issue (and add a With the Rust API in wasmtime using // Assuming we've created our store/component/linker, and the world name is
// ``Runtime`.
let (bindings, _) = Runtime::instantiate(&mut store, &component, &linker)?;
let clients = bindings.component_runtime_clients(); // 'interface clients'
let placeholder = clients.placeholder(); // 'resource placeholder'
let resource_instance = placeholder.call_constructor(&mut store, "myname")?; // constructor(name: string)
let result = placeholder.call_hello_world(&mut store, resource_instance)?; // hello-world: func() -> stringSo if we wanted that same API in Python, that would look something like: from wasmtime import Store
from .generated import Root
store = Store()
runtime = Root(store)
clients = runtime.clients() # 'interface clients'
placeholder = clients.placeholder(); # 'resource placeholder'
resource_instance = placeholder.constructor(store, "myname") # 'constructor(name: string)'
result = placeholder.hello_world(store, resource_instance) # hello-world: func() -> stringHowever, I think ideally we'd invoke methods on the instantiated resource directly (e.g. import * as runtime from "./bindings/runtime.js";
// We could just do:
//
// const instance = new runtime.clients.Placeholder('myname')
//
// But breaking out each step to compare with the Rust bindgen!()
const clients = runtime.clients; // 'interface clients'
const Placeholder = clients.Placeholder; // 'resource placeholder'
const resourceInstance = new Placeholder('myname'); // 'constructor(name: string);'
const result = resourceInstance.helloWorld(); // 'hello-world: func() -> string'I'm not sure how feasible this is, but maybe something along these lines could work for Python: store = Store()
runtime = Root(store)
clients = runtime.clients() # 'interface clients'
Placeholder = clients.Placeholder; # 'resource placeholder'
resource_instance = Placeholder(store, "myname") # 'constructor(name: string)'
result = resource_instance.hello_world(store) # hello-world: func() -> string |
|
Given how different the ownership idioms are in Rust and Python I'd definitely recommend following jco's footsteps here more than Wasmtime's, and what you have there all looks reasonable to me! |
I appears that having a wit
resourcetype in a component definition causes wasmtime-py to throw an error when generating bindings.The following .wit file:
Implemented by this Rust code:
and compiled using:
Throws the following error:
Full Error
The
NotImplementedErrorat the end seems to be caused by theresourcein the wit. Changing the wit to just nest the function directly under theinterface(and making the corresponding changes to the rust code) resolves the issue.The text was updated successfully, but these errors were encountered: