exposing wasmtime's capabilities · cargo-component

Heya; a common issue I've run into when using cargo-component is that there is no convenient way to pass flags to wasmtime. For example when building a wasi:http/proxy-based application, I want it to work with wasmtime serve rather than wasmtime run.

Or when building a TCP-based application, I want it to be able to be able to open sockets or listen for connections. But right now there is no way to configure that.

My intuition here is that we would want some kind of "capabilities" entry in Cargo.toml which explains which capabilities the runtime needs to provide. And wasmtime is able to expose that. But before I go and propose any specific design or do anything in that direction, I wanted to check whether this is something people had thought of before?

Lann Martin (Sep 05 2024 at 15:03):

I've thought about it in the context of writing wasi http proxy components that could work on both Spin and wasmtime serve. Spin did its own thing here in large part because there is no standardized way to represent these capabilities.

Taylor Thomas (Sep 05 2024 at 16:57):

Not sure I follow here. Running the component is separate from building it, which is what cargo component does. The "capabilities" needed can be figured out from the world. But I figure I am missing something

Yoshua Wuyts (Sep 05 2024 at 17:02):

cargo component also runs it via e.g. cargo component run. Take for example this tcp example - if you try to use that in your Rust project an run it with cargo component run, it will always error.

Taylor Thomas (Sep 05 2024 at 17:11):

Ew...I just found out we have that and that it is ugly (example from the test below):

cargo_component(["run"])
        .env(
            "CARGO_TARGET_WASM32_WASIP1_RUNNER",
            "wasmtime --env APP_NAME=CargoComponent -C cache=no -W component-model -S preview2 -S cli",
        )

I think I would prefer our own custom run command instead where we could embed wasmtime. It is pretty easy to figure out what you need to provide to the component by inspecting the world, so if cargo component run sees wasi:http/incoming-handler it could automatically serve for you. However, I still hesitate to add this functionality. I know that in practice it could be really nice, but you can then only support things that are available in wasmtime. That means no custom interfaces (which almost everyone does when they start doing anything for real with wasmCloud for example), and only support for interfaces that are in wasmtime. So that means no blobstore/messaging/etc until those land in wasmtime or we put them directly into cargo component

Yoshua Wuyts (Sep 06 2024 at 13:20):

Re: whether we should have this - from a Rust programmer's perspective having cargo component Just Work is pretty important for the overall user experience.

Our goal should be for library authors to be able to treat WASI 0.2 as just another target to support - no different than macOS, Windows, or Linux. And that means having access to e.g. cargo test and cargo run that work without extra hassle.

Yoshua Wuyts (Sep 06 2024 at 13:21):

That's mostly scoped around making sure wasi:cli/command Just Works out of the box.

Taylor Thomas (Sep 06 2024 at 16:07):

I just think that many people will be using a lot more than wasi:cli and wasi:http so any story needs to support slotting in custom things

Stream: cargo-component

Topic: exposing wasmtime's capabilities

Yoshua Wuyts (Sep 05 2024 at 15:01):