Hello!
I'm trying to source WASI types generated by wit_bindgen
from another crate, but I'm running into problems. To clarify, the WIT world for my component depends on some WASI types, e.g.:
world my-world {
use other-types.{outcome};
use wasi:http/types@0.2.0.{incoming-request};
import wasi:http/outgoing-handler@0.2.0;
export handle: func(incoming: incoming-request) -> outcome;
}
When I run wit_bindgen
on this world, the generated code includes code for the WASI types/handler. Instead, I'd like to be able to generate the WASI-specific code needed for the component in another crate, and have the component reference it.
A naive approach I took, removing the WASI implementations from the generate code for my-world
, and replacing them with references to the corresponding types generated in the dependent crate. This ended up failing with the error when encoding the component:
failed to load xxx: updating metadata for section component-type:internal
Caused by:
0: failed to merge worlds from two documents
1: duplicate import found for interface `incoming-request`
For context, the world internal
only includes the necessary WASI types (the outgoing-handler, and incoming-request type)
Is there another approach I can take? Is this possible?
Thank you!
What guest language are you using? (assuming guest here because wit_bindgen
is being used, but if a host is being used please correct me). If you're using Rust the with
option is intended to solve this use case, although it may not be fully complete yet.
Also, if you can, can you capture the inputs to generate that error and file an issue if you get a chance? That's not a great error message and something we should improve
Sorry, forgot to mention that my guest language is Rust! Yes, I tried using with
but unfortunately I still found that wasi
code was still generated. Do you know if there's a workaround in the meantime? FYI, with
works as expected in my Rust host environment when using wasmtime::component::bindgen!
.
And yes, will definitely file an issue with code to repro!
I'm not aware of a workaround myself, but please feel free to file an issue for this as well
Last updated: Dec 23 2024 at 14:03 UTC