-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cargo-wasix as the successor to cargo-wasi #33
Comments
Looks like it currently also requires And Fixing these little things would also be good in order to recommend |
Hey @jedisct1 , at the moment It uses the 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 One option would be defaulting to WASIX, but offering a flag / env var / custom Cargo.toml metadata to use |
Could it install a |
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
is being archived, so users need a replacement.cargo-wasix
could be what we should use and recommend instead. But it currently requires/install thewasix-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 towasix
? And maybe provide acargo wasi
command for people who need a maintained version ofcargo wasi
?The text was updated successfully, but these errors were encountered: