Stream: general

Topic: re-using types from different bindings

view this post on Zulip dakom (Jan 14 2025 at 17:49):

I have a wit file which I use in several different components... when I generate the bindings, even through the same tooling (e.g. cargo-component or wit-bindgen), I get conflicts that the type in component_a::Foo is different than component_b::Foo - even though they're both importing the same wit and using the same world

is this a known issue? any tips for working around this other than writing macros to convert the types?

view this post on Zulip Dan Gohman (Jan 14 2025 at 18:47):

One option that I've seen some projects do is factor out the bindings into a separate crate. That is, put a wit bindgen generate!() in src/lib.rs in its own crate that your other crates can depend on.

view this post on Zulip dakom (Jan 15 2025 at 06:45):

that would definitely work... but I'm building the components with cargo component build and it wants to know the world, generate its own bindings, etc.. with this approach, I guess I'd need to bypass cargo component and do things more manually? will check into it, thanks!

view this post on Zulip Ralph (Jan 15 2025 at 14:31):

in almost every single component model I've ever seen over the past 30 years, data types are always their own "component"/"package"/"shareable thing". I'll be STUNNED if the wasm component model can pull this off or any language chain.

view this post on Zulip Ralph (Jan 15 2025 at 14:31):

but, as you might imagine, I'd looooooooooove* to be surprised here.

view this post on Zulip Ralph (Jan 15 2025 at 14:31):

:-)

view this post on Zulip dakom (Jan 16 2025 at 08:11):

fwiw, I went down a few rabbit holes... the most promising for a general solution was probably something like:

  1. all bindings for components in one shared crate
  2. macros to convert the types used between worlds, if needed
  3. do the same on the host side (wasmtime bindings)
  4. more macros to convert between host and guest bindings

it worked, but kinda ugly...

turns out for my use-case I don't need the macros - just have a shared lib with the bindings, and use variants to handle more usecases where I would have maybe wanted different worlds before.

I do think tooling to handle the problem of "I have a .wit that's used in a bunch of places, but bindings are incompatible" would be nice - especially where it's multiple worlds generated as distinct bindings but from the same exact interface imports

view this post on Zulip Ralph (Jan 16 2025 at 10:00):

Everyone wants it, of course. My guess is that if you have your data types in a separate wit, witbindgen should be able to export both guest and host parts properly.

Last updated: Jan 24 2025 at 00:11 UTC