cargo-wasix as the successor to cargo-wasi
Opened this issue · 5 comments
cargo-wasi is being archived, so users need a replacement.
cargo-wasix could be what we should use and recommend instead. But it currently requires/install the wasix-libc as well as an old Rust toolchain. This may not be desirable, and is an issue for packaging.
Would it be reasonable to only download the wasix components when actually compiling to wasix? And maybe provide a cargo wasi command for people who need a maintained version of cargo wasi?
Looks like it currently also requires wasmer to be present.
And cargo wasix build doesn't work when Rust was not installed with rustup.
Fixing these little things would also be good in order to recommend cargo-wasix as the replacement for cargo-wasi.
Hey @jedisct1 , at the moment cargo-wasix is geared towards WASIX.
It uses the wasm32-wasmer-wasi target by default, runs a wasm-opt pass with the --asyncify enabled (because WASIX requires it for fork/exec), and as you've noticed, currently requires rustup and uses wasmer as the default runtime.
The rustup dependency is something we'd like to get rid of anyway, and making the runtime configurable was also always a target and wouldn't be hard.
The main challenge would be deciding between regular wasm32-wasi and WASIX targets without regressing the user experience.
I general we'd definitely be open to making cargo-wasix also fill the shoes of cargo-wasi, as long as we can resolve the above in a satisfactory way.
One option would be defaulting to WASIX, but offering a flag / env var / custom Cargo.toml metadata to use wasm32-wasi instead.
Could it install a cargo-wasi command in addition to cargo-wasix?
Duh, that's much more sensible.
It can be just the same binary (copied/symlinked as cargo-wasix and cargo-wasi), and we detect what to do based on the command name.
We'll tackle the rustup and configurable engine ourselves, but we'll probably be hard-pressed to find cycles for the cargo-wasi compat mode, and would wait for an outside contribution.