Could cargo-component auto-compose components?

[alexcrichton]

Currently if I add a [package.metadata.component.dependencies] section to a component with path = '...' the final output of cargo component build has an import of an instance. Could it be possible to automatically run wasm-tools compose or the equivalent thereof to have the final component bundled in the artifact?

Naively I thought this already happened, so I figure that an option, even if off-by-default, might be good to have

[peterhuene]

We want to keep the instance imports (ideally with the import metadata pointing at what we expect to link with) in the build output as well as in the component published to a registry as composition should be happening at a later stage than producing an individual component.

I was sort of envisioning cargo component run or cargo component test to be the place where composition would take place, but those commands haven't been fleshed out yet.

[alexcrichton]

Ah ok so this would perhaps be a use case for https://github.com/WebAssembly/component-model/pull/222 and wasm-tools compose could perhaps compose the final component automatically with no extra information given given those import names?

[peterhuene]

Yeah, I think that's the idea.

We'd pass through that information from cargo-component in the imports to name implementations, allowing, by default, the composition tooling to link the dependencies in automatically, as transitively as possible, assisted by the registry to resolve versions.

Any missing details (i.e. a named import or interface import) would perhaps require a composition definition (something similar to WIT; not the YAML nonsense the tool currently supports).

[vwkd]

+1 on supporting composition in cargo run and cargo test. Much needed to run multiple components locally before deploying them somewhere.

How would this work? Does it need to compile to WASM or could it hook up and run the Rust crates directly? Would probably be easier to use cargo’s existing test feature than to built a new one on top of Wasm (e.g. parallel tests, stacktraces, etc.)? Although what if the component has compiled Wasm (non-Rust) dependencies?

[esoterra]

Also, it's not quite as simple as just composing. The operations we're really talking about are "locking" and "bundling", which both require the depsolve logic to be finished. That said, when it is ready I could see a use case for having --locked and --bundled options for building that give you those if you want them.