The future of wasm-tools compose given wac

[rylev]

With wac now in the Bytecode Alliance GitHub org and releasing to crates.io, there is a viable alternative to wasm-tools compose. In theory, wac should be capable of everything that wasm-tools compose is capable of plus more, and there doesn't seem to be a point in continuing development of both tools.

Where to go in the long term

Broadly, I see two alternatives of where to go in the medium and long term:

• Completely deprecate wasm-tools compose in favor wac eventually removing the subcommand altogether.
• Leave a wasm-tools compose subcommand that is implemented in terms of wac primitives.

Those who only need simple composition scenarios and already have wasm-tools installed may prefer the approach of keeping wasm-tools compose instead of requiring the installation of a new tool. However, maintaining both tools might be too much maintainence overhead.

Where to go in the short term

In the short term, I would propose deprecating wasm-tools compose by emitting a deprecation warning when invoked. This deprecation warning would direct folks to the wac repository. All issues opened on the wasm-tools repo that have to do with wasm-tools compose would be answered by directing users towards wac.

[alexcrichton]

The short term sounds good to me and I'd be tempted to go with "remove compose in the long-term" entirely to avoid the confusion of which-tool-does-what.

[NewGyu]

Does the above discussions mean that the subcommand equivalent to wac will not be integrated into wasm-tools in the future either? It feels somewhat strange that wasm-tools component (new|wit) continues to be subcommands in the wasm-tools, but compose alone is removed.

[alexcrichton]

Currently there aren't concrete plans to move wac into wasm-tools. I'm not personally opposed to that insofar that it's generally nicer to only have to worry about one tool rather than multiple tools. At the same time though wac is much more ambitious than many of the tools in wasm-tools so it might make the most sense long-term to keep them separate. In general wasm-tools component {new,wit} are pretty low-level and it might make more sense to integrate the subcommands from wasm-tools into wac instead of the other way around. For example wac could automatically take core wasms as input and componentize them on-the-fly along the lines of wasm-tools component new.

[alexcrichton]

The deprecation bits have now landed so I'm going to close this. In the future when necessary we can consider removing wasm-tools compose