Landon James (Feb 02 2024 at 19:49): Landon James (Feb 02 2024 at 19:49):Hello, I'm with AWS and on a sister team with the AWS Rust SDK. I'm working with them to get this PR adding wasi support merged (authored by @Eduardo Rodrigues ). Have a few questions since it seems like preview2 is finalized and published now:
http_client from? It seems it hasn't been updated in awhile and I couldn't find it on GH so wondering if it might have moved to a non-prototype crate somewhere?wasm32-wasi target and adding explicit preview1/preview2 targets. When the preview2 target is published how does this strategy change? Do we no longer need to explicitly pull in the http_client from that crate because it is compiled in with the wasi-sdk? Alex Crichton (Feb 02 2024 at 20:10):I'm working to update the wasi crate on crates.io to 0.12.0 in which is intended to be an "official" place to pull in generated bindings from
When the preview2 target is published how does this strategy change?
Publication is probably going to Rust 1.78 if everything goes according to plan (watch for updates here).
That won't change what you write in crates but it'll change your build process. Today where you use wasm32-wasi then wasm-tools component new tomorrow you'd just build with the wasi 0.2 target and a component would pop out.
Do we no longer need to explicitly pull in the http_client from that crate because it is compiled in with the wasi-sdk?
I'm not 100% sure what you mean by the http_client crate, but I think the answer to your question is "you'd write the same code" and your build process would be the main thing to change
Alex Crichton (Feb 02 2024 at 20:11):I'll note that the wasi 0.2 target in rustc is intended to be tier 3 to start while we develop it, so if you want to rely on something I'd stick to the wasi 0.1 ("preview1") target for the time being
Eduardo Rodrigues (Feb 02 2024 at 21:21):@Landon James The original http_client feature is located here (but not up-to-date with WASI v0.2.0 as you noted):
https://github.com/bytecodealliance/preview2-prototyping/blob/main/wasi/src/http_client.rs
Eduardo Rodrigues (Feb 02 2024 at 21:25):I would stick with the suggestion provided by Alex (using the binding from the wasi crate). You can take the example from the previously implemented crate (to convert from wasi shapes to the rust http) and from the tests at wastime here: https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi-http/tests/all/main.rs
Landon James (Feb 05 2024 at 19:57):Awesome, thank you both for the pointers! I'll get started on it once the changes to the wasi crate are published.
Landon James (Feb 13 2024 at 03:43):Alright, updated questions. I'm almost done with this and am just updating the tests. I've updated the wasmtime dependency to 17.0.0 and custom test runner to :
[target.wasm32-wasi]
runner = [
"wasmtime",
"-C", "cache=n",
"-S", "preview2=y",
"-S", "http=y"
]
Which does attempt to run the binary with wasmtime, but this fails with Error: Cannot enable wasi-http for core wasm modules and that makes sense because nothing in the cargo test pipeline runs wasm-tools component new on the resulting core wasm module. Seems like this will be fixed with wasm32-wasi-preview2 which will by default output a component.
Until that is ready does anyone know of a good way of getting the componentization into a cargo test pipeline without doing too much custom work?
Also, just want to check my assumption that since I am consuming the wasi::http module via the wasi crate I no longer need to manually include the wasi:http wit files directly in my project?
Peter Huene (Feb 13 2024 at 04:44):cargo-component supports a test subcommand; I can't say if that's suitable for what you need or not
Landon James (Feb 13 2024 at 20:02):Ahh perfect, cargo-component did exactly what I need, thank you!
Last updated: Dec 23 2024 at 12:05 UTC