Consider archiving cargo-wasi repository #143
Comments
|
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 |
|
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. |
|
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 |
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`.
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`.
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`.
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`.
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-bindgenmay 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:
cargo wasitool should effectively be replaced bycargo componentwasm-bindgenis quite outdated and no longer relevant. The wasm-bindgen tool only ever supportedwasm32-wasiat best and it's been explicitly removed now as wellWhile
cargo wasiwas 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 thatcargo componentis the effective successor of this tool and usage/tooling should be directed towards that.The text was updated successfully, but these errors were encountered: