I was trying to use wasmtime serve
today but ran into dependency problems: what is the set of versions and build options that will allow that to work?
I am currently (1) retrieving WIT dependencies with wit-dep
, (2) building a simplistic (and raw) HTTP server by exporting ""wasi:http/incoming-handler"
with wit-bindgen
, (3) putting the pieces together using wasm-tools component new
(including the preview1 adapter) and (4) attempting to run this with wasmtime serve
. I invariably get errors like "import wasi:cli/environment@0.2.0-rc-2024-01-16
has the wrong type`."
I suspect that what is going on is that the preview1 adapter is bringing in unnecessary dependencies (unnecessary to my test program, I mean). I'm not sure why they would have the wrong type, seeing as I'm using Wasmtime on main
.
I have looked at @Brooks Townsend's guide (here) for how to do this with the wash
CLI but I wanted to understand all the pieces in raw form. Is there no working example for wasmtime serve
somewhere?
This is likely related to the adapter you're using. If you're using *.reactor.wasm
you'll need to pass -S common
to enable access to APIs not in the default proxy world. Otherwise you'll need to use *.proxy.wasm
to not need -S common
I only see wasi_snapshot_preview1.wasm
when I build the adapter with cargo build -p wasi-preview1-component-adapter --target wasm32-unknown-unknown --release
ah if building from source you'll need to frob cargo features
ok, let's try that
I think you'll need --no-default-features --features proxy
Ok, that works:
# In Wasmtime:
$ cargo build -p wasi-preview1-component-adapter --target wasm32-unknown-unknown --release --no-default-features --features proxy
$ ll -h target/wasm32-unknown-unknown/release/wasi_snapshot_preview1.wasm
-rwxr-xr-x. 2 abrown abrown 28K Jan 29 12:19 target/wasm32-unknown-unknown/release/wasi_snapshot_preview1.wasm
# In example project:
$ wasm-tools component new ./target/wasm32-wasi/debug/test_wasi_http.wasm \
-o target/wasm32-wasi/debug/test-component.wasm \
--adapt ../wasmtime/target/wasm32-unknown-unknown/release/wasi_snapshot_preview1.wasm
$ wasm-tools component wit target/wasm32-wasi/debug/test-component.wasm
package root:component;
world root {
import wasi:io/error@0.2.0;
import wasi:io/streams@0.2.0;
import wasi:http/types@0.2.0;
import wasi:cli/stdout@0.2.0;
import wasi:cli/stderr@0.2.0;
import wasi:cli/stdin@0.2.0;
export wasi:http/incoming-handler@0.2.0;
}
That seems like the right number and kind of imports; way fewer than I was seeing earlier. And just a note: I don't see any special *.proxy.wasm
or *.reactor.wasm
in the adapter.
When you say "in the adapter", can you clarify? I should clarify when I say *.proxy.wasm
I mean from Wasmtime's releases page where we manually rename a few things
And wasmtime serve
now works:
$ wasmtime serve target/wasm32-wasi/debug/test-component.wasm
Serving HTTP on http://0.0.0.0:8080/
Note that -Scommon
isn't necessary with the proxy version of the adapter
[edited to remove that part]
Alex Crichton said:
When you say "in the adapter", can you clarify? I should clarify when I say
*.proxy.wasm
I mean from Wasmtime's releases page where we manually rename a few things
I mean that when I build the adapter from source, I do not see any special file name suffixes. I didn't know to look in the release artifacts?
Oh you're correct that there's no suffix when building from source
I looked around in the Wasmtime repository for a CLI test of some kind that does all of this: did I miss it or is that just not there yet?
And by artifacts I mean at the top level of this page, not within tarballs themselves
This is the closest equivalent to in-repo tests
Last updated: Dec 23 2024 at 12:05 UTC