Bug: Wit worlds incorrectly merged with remote SDK

[jamesstocktonj1]

Description

FYI I'm loving the componentize-go.toml change, it really cleans up some of my Go projects!

I've run into a little issue where my sdk's wit incorrectly merges with the local WIT.

Reproduction

I currently have the following wit defined in my sdk:

world sdk {
  include wasi:http/proxy@0.2.0;
  ...
}

In my local wit I add some extra features, but it also re-defines the wasi:http/outgoing-handler:

world bat {
  import wasi:http/outgoing-handler@0.2.0;
  ...
}

After building and running I get the following error from wasmtime:

$ componentize-go --world bat --wit-path ./wit build --output build/hello.wasm
$ wasmtime serve --addr 0.0.0.0:8000 -Scli build/hello.wasm
Starting wasmtime
Error: no exported instance named `wasi:http/incoming-handler@0.2.6`

Inspecting the built wasm results in the following:

$ wash inspect build/hello.wasm 
package root:component;

world root {
  import wasi:io/poll@0.2.6;
  import wasi:clocks/monotonic-clock@0.2.6;
  import wasi:io/error@0.2.6;
  import wasi:io/streams@0.2.6;
  import wasi:http/types@0.2.0;
  import wasi:http/outgoing-handler@0.2.0;
  import wasi:cli/environment@0.2.6;
  import wasi:cli/exit@0.2.6;
  import wasi:cli/stdin@0.2.6;
  import wasi:cli/stdout@0.2.6;
  import wasi:cli/stderr@0.2.6;
  import wasi:cli/terminal-input@0.2.6;
  import wasi:cli/terminal-output@0.2.6;
  import wasi:cli/terminal-stdin@0.2.6;
  import wasi:cli/terminal-stdout@0.2.6;
  import wasi:cli/terminal-stderr@0.2.6;
  import wasi:clocks/wall-clock@0.2.6;
  import wasi:filesystem/types@0.2.6;
  import wasi:filesystem/preopens@0.2.6;
  import wasi:random/random@0.2.6;
}

It seems to have included the import wasi:http/outgoing-handler@0.2.0 but missed out the export wasi:http/incoming-handler@0.2.0.

Troubleshooting:

• I have tried both using include wasi:http/proxy@0.2.0; defining both incoming-handler and outgoing-handler
• Removing the outgoing-handler in the local wit fixes the issue (sdk wit is correctly used)

[asteurer]

Just to double check that this isn't a typo, it looks like wasmtime is expecting wasi:http v0.2.6 when you are providing it v0.2.0. If that isn't a typo, will you see if matching the wasi:http package versions fixes your issue?

[jamesstocktonj1]

Good spot, I have had v0.2.0 working for client / host. Tried bumping the version for a sanity check and didn't change anything.

Just to point out if I remove the --world bat --wit-path ./wit or comment out the import outgoing-handler the component compiles and exports incoming-handler as expected.

[jamesstocktonj1]

Looks like when I specify the --wit-path it ignores any of the sdk componentize-go.toml files. Is this expected behaviour?

[asteurer]

Yeah, that's expected behavior. I'll make a note to better document this. If you're interested, here's the PR where this was discussed (it's in one of the resolved review comments): #35. Basically, the workaround is that you need to specify ALL worlds--including those in the componentize-go.toml files--when you use the --world args in componentize-go.

In your case, I'm pretty sure you'd need to run the following:

componentize-go --world bat --world sdk --wit-path ./wit build --output build/hello.wasm

[jamesstocktonj1]

Amazing that's solved it and makes a lot more sense now!

My only pointer on this is that perhaps remote worlds should be referred to by their full name (e.g. some:package/world) rather than just their world. I can see a lot of packages calling their world something non-unique such as sdk.

[asteurer]

Yeah, that's a great point and something I plan to document as well. Thanks James!