Skip to content
This repository was archived by the owner on Feb 14, 2025. It is now read-only.

Consider archiving cargo-wasi repository #143

Open
alexcrichton opened this issue Aug 7, 2023 · 3 comments
Open

Consider archiving cargo-wasi repository #143

alexcrichton opened this issue Aug 7, 2023 · 3 comments

Comments

@alexcrichton
Copy link
Member

This tool was written quite some time ago and quite a lot has changed in the meantime. When this tool was first written the component model didn't exist and the future of WASI was not so certain. Additionally at the time this tool was written it was envisioned that wasm-bindgen may play a part in the future story of bindings generation and such. Nowadays much of the original underlying assumptions of this tool are no longer applicable.

Today the landscape is significantly different:

  • WASI is defined with the component model which has its own suite of tooling and such where a thin wrapper around Cargo, which this tool is, is not appropriate.
  • The cargo wasi tool should effectively be replaced by cargo component
  • Integration/support for wasm-bindgen is quite outdated and no longer relevant. The wasm-bindgen tool only ever supported wasm32-wasi at best and it's been explicitly removed now as well

While cargo wasi was a neat experiment I personally have not really been maintaining it for quite awhile now and I think the usage is quite small today (although I believe there are some users). I'm not keen myself on the continued support of this tool because it causes confusion for example being in a prominent location with a prominent name. Personally I think it would be best to update the README to document the current state of play as-of-today and indicate that cargo component is the effective successor of this tool and usage/tooling should be directed towards that.

@alexcrichton
Copy link
Member Author

I'll also note that this tool is not current planned to follow the developments of WASI meaning that it'll be stuck on preview1 "forever". Integration with components and continuing to follow WASI would require basically duplicating the efforts of cargo component which if that's the case means that effort should go there instead of here.

@dj95
Copy link

dj95 commented Dec 17, 2023

I really appreciate the new approach and the component model. It looks really promising. Do you plan to support wasm32-wasi in cargo-component?

Currently I develop and maintain a WASM plugin for a terminal multiplexer (zellij). They support plugins with wasm32-wasi as compilation target. In order to run unit tests and benchmarks for profiling, cargo-wasi provides an easy way to run these tasks. Are these tasks possible with cargo-component? Unit tests seem to work fine, but benchmarks with criterion seem not to work.

@alexcrichton
Copy link
Member Author

Yes wasm32-wasi is already supported by cargo-component as it's the only means by which is implemented to create a component right now

tommy added a commit to Stedi/jsonata-rs that referenced this issue Feb 3, 2025
The `wasm32-wasi` target has been renamed to `wasm32-wasip1`:

<https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html>

The `cargo-wasi` crate is also outdated and being replaced with
`cargo-component` for creating WASI components. It does not support the
new target name.
<bytecodealliance/cargo-wasi#143>

However, this project doesn't currently define a WASI component, so we
can't use cargo-component to build or run tests. We do want to verify
that the project builds correctly for the WASM targets, so this change
runs the compiled test targets directly with `wasmtime`.
tommy added a commit to Stedi/jsonata-rs that referenced this issue Feb 3, 2025
The `wasm32-wasi` target has been renamed to `wasm32-wasip1`:

<https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html>

The `cargo-wasi` crate is also outdated and being replaced with
`cargo-component` for creating WASI components. It does not support the
new target name.
<bytecodealliance/cargo-wasi#143>

However, this project doesn't currently define a WASI component, so we
can't use cargo-component to build or run tests. We do want to verify
that the project builds correctly for the WASM targets, so this change
runs the compiled test targets directly with `wasmtime`.
tommy added a commit to Stedi/jsonata-rs that referenced this issue Feb 3, 2025
The `wasm32-wasi` target has been renamed to `wasm32-wasip1`:

<https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html>

The `cargo-wasi` crate is also outdated and being replaced with
`cargo-component` for creating WASI components. It does not support the
new target name.
<bytecodealliance/cargo-wasi#143>

However, this project doesn't currently define a WASI component, so we
can't use cargo-component to build or run tests. We do want to verify
that the project builds correctly for the WASM targets, so this change
runs the compiled test targets directly with `wasmtime`.
tommy added a commit to Stedi/jsonata-rs that referenced this issue Feb 3, 2025
The `wasm32-wasi` target has been renamed to `wasm32-wasip1`:

<https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html>

The `cargo-wasi` crate is also outdated and being replaced with
`cargo-component` for creating WASI components. It does not support the
new target name.
<bytecodealliance/cargo-wasi#143>

However, this project doesn't currently define a WASI component, so we
can't use cargo-component to build or run tests. We do want to verify
that the project builds correctly for the WASM targets, so this change
runs the compiled test targets directly with `wasmtime`.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants