How to restrict import of unused features required by string type?

[XX]

When I make a simple .wit using the string type, like this:

package component:add;

world example {
    export add: func(x: string, y: u8) -> string;
}

after building and running I get a request to add a bunch of additional interfaces:

$ wasm-tools component wit ./target/wasm32-wasip1/release/add.wasm 
package root:component;

world root {
  import wasi:cli/environment@0.2.0;
  import wasi:cli/exit@0.2.0;
  import wasi:io/error@0.2.0;
  import wasi:io/streams@0.2.0;
  import wasi:cli/stdin@0.2.0;
  import wasi:cli/stdout@0.2.0;
  import wasi:cli/stderr@0.2.0;
  import wasi:clocks/wall-clock@0.2.0;
  import wasi:filesystem/types@0.2.0;
  import wasi:filesystem/preopens@0.2.0;

  export add: func(x: string, y: u8) -> string;
...

In particular, after running:

$ cargo run -p host -- 2 3 target/wasm32-wasip1/release/add.wasm
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.83s
     Running `target/debug/host 2 3 target/wasm32-wasip1/release/add.wasm`
Error: Failed to instantiate the example world

Caused by:
    0: component imports instance `wasi:cli/environment@0.2.0`, but a matching implementation was not found in the linker
    1: instance export `get-environment` has the wrong type
    2: function implementation is missing

But my component should not have the right to get environment variables and do other things. How can I do this?

[vados-cosmonic]

Hey @XX so when you build a component in Rust, those imports are needed for the backtrace machinery.

There's a discussion on Zulip around exactly why that is.

The resulting solutions aren't great (either building for an explicitly non-component target or using nightly rust to remove the default panic machinery), but the discussion should be helpful to you!

Unfortunately to run the component as-is in a host embedding, you'll need to link in WASI dependencies.

[XX]

@vados-cosmonic So there is no way to restrict a component in using environment variables and other things if it uses a string in interfaces? Because only for integer types in the .wit file such imports are not required.

[dicej]

It's been a while since I tried it myself, but have you tried using the wasm32-unknown-unknown target when building? On Dec 31, 2024 11:20 AM, Alexander Mescheryakov ***@***.***> wrote: @vados-cosmonic<https://github.com/vados-cosmonic> So there is no way to restrict a component in using environment variables and other things if it uses a string in interfaces? Because only for integer types in the .wit file such imports are not required. — Reply to this email directly, view it on GitHub<#433 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAJPQEOPEFF2PSRN2WDX7T32ILN7HAVCNFSM6AAAAABUMFCSICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRWGY2DCMRVGI>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[XX]

@dicej No, I didn't fully understand what was required. In my case, it was enough to add the necessary interfaces to the linker on the host to make everything work:

let mut linker = Linker::<States>::new(&engine);
wasmtime_wasi::add_to_linker_sync(&mut linker)?;

The component still won't have access to the stdout, file system etc. until I set up access via context. For example, to access stdout:

pub struct States {
    table: ResourceTable,
    ctx: WasiCtx,
}

impl States {
    pub fn new() -> Self {
        let table = ResourceTable::new();
        let ctx = WasiCtxBuilder::new()
            .stdout(wasmtime_wasi::stdout()) // <----- by default stdout is closed, using the host's native stdout
            .build();
        Self { table, ctx }
    }
}

impl WasiView for States {
    fn table(&mut self) -> &mut ResourceTable {
        &mut self.table
    }

    fn ctx(&mut self) -> &mut WasiCtx {
        &mut self.ctx
    }
}

But if I still needed to get rid of unnecessary imports, I would take the advice to use the nightly compiler and recompile the std with panic_immediate_abort feature:
https://bytecodealliance.zulipchat.com/#narrow/channel/217126-wasmtime/topic/wasi.20pulled.20in.20unintentionally/near/490269017
Thank you @vados-cosmonic

[vados-cosmonic]

Hey @XX glad you were able to get the host working (IMO the world is a lot more interesting with the WASI imports :)

That said, hopefully you saw the discussion and Joel's specific recommendation (I should have called it out like he did!) -- for super simple components you can use wasm32-unknown-unknown as a target, and you won't get the WASI deps (by default)

[XX]

@vados-cosmonic Yes, but in my case the component should be able to work with fs, environment variables etc., but only if the user of the host program has granted permissions.

[vados-cosmonic]

Ah thanks for clarifying! Glad you were able to get the issue sorted :)

[lukewagner]

(Sorry for the slow reply; getting back from holidays) Thanks so much @vados-cosmonic for the helpful comments. I think it's a really important topic for how to get producer toolchains not to pull in additional imports not declared in the target world, but since it's not an issue that the component-model (spec) can solve on its own, but rather a particular language producer toolchain, I'll close this for now. But feel free to reopen if there's anything more spec-related though.