Skip to content
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

Open
jedisct1 opened this issue Aug 7, 2023 · 5 comments
Open

cargo-wasix as the successor to cargo-wasi #33

jedisct1 opened this issue Aug 7, 2023 · 5 comments
Labels
enhancement New feature or request

Comments

@jedisct1
Copy link

jedisct1 commented Aug 7, 2023

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?

@jedisct1
Copy link
Author

jedisct1 commented Aug 7, 2023

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.

@theduke
Copy link
Collaborator

theduke commented Aug 13, 2023

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.

@theduke
Copy link
Collaborator

theduke commented Aug 13, 2023

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.

@jedisct1
Copy link
Author

Could it install a cargo-wasi command in addition to cargo-wasix?

@theduke
Copy link
Collaborator

theduke commented Aug 14, 2023

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.

@theduke theduke added the enhancement New feature or request label Aug 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants