Functions of import of an import end up in bindings

[peter-facko]

I am testing working with wasm components. I have four components, A, B1, B2, C with a diamond layout.

C
|\
| \
↓  ↓
B1 B2
 \ /
  ↓
  A

The packages are as follows

A:

package example:a@0.1.0;

interface %interface {
    record blob {
        x: f64,
    }

    f-a: func(x: f64) -> blob;
}

world %world {
    export %interface;
}

B1:

package example:b1@0.1.0;

interface %interface {
    use example:a/%interface@0.1.0.{blob};

    f-b1: func(x: f64) -> blob;
}

world %world {
    import example:a/%interface@0.1.0;

    export %interface;
}

B2:

package example:b2@0.1.0;

interface %interface {
    use example:a/%interface@0.1.0.{blob};

    f-b2: func(x: f64) -> blob;
}

world %world {
    import example:a/%interface@0.1.0;

    export %interface;
}

C:

package example:c@0.1.0;

interface %interface {
    f-c: func(x: f64) -> f64;
}

world %world {
    import example:b1/%interface@0.1.0;
    import example:b2/%interface@0.1.0;

    export %interface;
}

The generated bindings for C contain function f-a from A. I don't think that is correct. Is C allowed to call f-a in this example? I get that it needs the type blob, but why f-a? Isn't that an implementation detail of B1 and B2?

If this behavior is correct, how do I make importing A an implementation detail of B1 and B2? Can they still share A then?

[dicej]

Hi, @peter-facko. Thanks for reporting this!

It looks like example:c/world is transitively importing example:a/interface due to the use statements in example:{b1,b2}/interface. Have you tried moving the blob type into its own interface in example:a, e.g.:

package example:a@0.1.0;

interface types {
    record blob {
        x: f64
    }
}

interface %interface {
    use types.{blob};

    f-a: func(x: f64) -> blob;
}

world %world {
    export %interface;
}

...and then updating b1 and b2's interfaces to use the types interface instead of the interface one?

FWIW, I don't think this is specific to componentize-py; I believe this is just how WIT (or at least wit-parser works). @alexcrichton might be able to confirm.

[alexcrichton]

@alexcrichton might be able to confirm

Correct yeah, this is how WIT/components work. Here blob is exported from A and used in B1/B2 directly, and in C transitively because it has to be able to talk about what it's importing from B1/B2 which requires talking about the resource from A.

Completely severing C's dependence on A would probably require not using resources at all in the exported functions of B1/B2, or to have B1/B2 export a resource which is used by C rather than using the imported resource from A

[peter-facko]

@dicej, thank you, splitting the interface solved this.