Make composing packages with dependencies easier?
I am just getting started with components, I and find it quite cumbersome to import other components. Let me try to illustrate my problem.
I am creating a component, depending on wasi-http, as such:
package component:adhoc;
/// An example world for the component to target.
world my-component {
include wasi:http/proxy;
}
and I'm importing the http component like that:
[package.metadata.component.target.dependencies]
"wasi:http" = { path = "../wasi-http/wit" }
Now the http component itself depends on other components:
wit
└── deps
├── cli
├── clocks
├── filesystem
├── io
├── random
└── sockets
I would expect that importing wasi:http would recursively import its dependency, but I instead need to individually specify paths to all my dependency's dependencies.
Is that a current rough edge, or am I misusing cargo component completely?
Happy to help.
Are you trying to target the wasi:http/proxy world with a component? (Creating an HTTP handler to respond to incoming requests.)
Hey @calvinrp thanks for helping out!
Actually I can get stuff working by just vendoring everything in my package wit/deps directory:
❯ tree -d -l wit
wit
└── deps
├── cli
├── clocks
├── filesystem
├── http
├── io
├── random
└── sockets
9 directories
but that's not very practical: as I add more dependencies, I need to copy their dependencies as well, and that makes managing all of that quite messy.
There should be a way to specify a dependency, give its path, and then recursively resolve dependencies (maybe there is already?)
Yeah, cargo component has 2 ways of resolving Wasm packages. The path way that you are using one way. It is pretty basic.
The other (primary) way is with wkg / wasm-pkg-client that enables registry packages as well as local paths. See the config docs for wkg which cargo component will inherit. Actively being worked on.
However, what it looks like from your examples, it is just wasi dependencies. If that's what you are after, it can be resolved very easily with the default registry configuration.
For instance, if you do, cargo component new --lib --target wasi:http/proxy http-example and then cargo component build. You have a component that targets the wasi:http/proxy world and generated bindings (in the ./src/bindings.rs file). Fetched from the OCI registry for the WASI packages. So no need to mess with the wit and wit/deps directory structure.
These are low-level bindings for wasi:http that aren't ergonomic. There are a few efforts under way for ergonomic solutions.