@Peter Huene Sorry for the lazy ask here, but how can I tell which versions of the wasi wit definitions are being used by cargo component
? Trying to figure out an issue where one of my components (that has transitive dep on streams that is being included by cargo component build
) seems to have a different version of streams than what is currently in https://github.com/WebAssembly/wasi-io/blob/main/wit/streams.wit
cargo component --version
will output the wasi adapter commit it's using, which corresponds to a commit in the wasmtime repo where the adapters are built out of
there's also now a feature in cargo-component
where you can point at the WASI adapter to use if you want to override the built-in
by setting package.metadata.component.adapter
in Cargo.toml
to point at the adapter module
The wits for the adapter are here: https://github.com/bytecodealliance/wasmtime/tree/main/crates/wasi/wit
Oh that is a handy feature. Thank you
@Taylor Thomas were you running into the following:
Caused by:
0: import `wasi:io/streams` has the wrong type
1: instance export `drop-input-stream` has the wrong type
2: expected func found nothing
I honestly can't remember
I don't think that was it
@David Justice what's the output of cargo component -V
?
$ cargo component -V
cargo-component-component 0.1.0 (465baa9 2023-09-27 wasi:aec4b25)
I could be totally wrong here but the version of the adapter aec4b25
(from that output) i think is the commit in wasmtime you need to checkout
Worth a shot.
Alternatively cargo component (as peter mentions above) has an adapter field in the Cargo.toml
that should allow you to set the version of the adapter to use i believe; I havent personally done this yet so im not 100% sure how to use it.
Yeah this seems to work:
> git checkout aec4b25
> cargo run --features component-model -- run --wasm-features component-model ../my-project/target/wasm32-wasi/debug/my-project.wasm
I wasn't entirely clear how the adapter config was to be used. So I did the following:
[package.metadata.component]
adapter = "../../../wasi/wit/main.wit" # points to the main.wit file in the wasmtime local repo I'm using to run the component
The component will compile, but fails after creating the component via:
error: decoding item in module
Caused by:
magic header not detected: bad magic number (at offset 0x0)
@David Justice Here's the PR adding the adapter
setting. TL;DR it takes a path to the WASI module adapter to use. So i suppose if you built the adapter yourself using wasmtime head you could pass that to cargo-component
via the adapter setting to enable running your command on wasmtime head :shrug: . Have never done this myself as i usually use the prebuilt adapters from the wasmtime release page or the builtin one from cargo-component.
I should definitely improve the error message, though. It is expecting a core module and not a wit file
It's pretty easy to build the adapter module out of the Wasmtime repo
Give me a sec to get to a computer and I'll paste the instructions
I see! That makes so much more sense. I'll give it a go and post back. Thank you, @Peter Huene
Here's the instructions for building the adapter out of the Wasmtime repo:
git checkout <rev>
cargo build -p wasi-preview1-component-adapter --target wasm32-unknown-unknown --release
cp wasm32-unknown-unknown/release/wasi_snapshot_preview1.wasm <path-to-component-project>
and then edit the component project’s Cargo.toml with adapter = "wasi_snapshot_preview1.wasm"
under [package.metadata.component]
(deleted)
I'm going to update cargo-component
's README to include this information
the not so great error message "decoding item in module" is coming from wasm-tools, but at least i can adorn it with some additional context from cargo-component
https://github.com/bytecodealliance/cargo-component/pull/151
Last updated: Nov 25 2024 at 19:03 UTC