component dependencies 2.0

[fibonacci1729]

The current implementation and design of component dependencies doesn't offer much in the way of developing components. It was conceived as a sort-of post development tool that enabled wiring up exports from dependencies to imports in my component. The responsibility of importizing dependencies was delegated to the developer.

The current syntax looks like this:

[dependencies]
"foo:bar@0.1.0" = { path = "path/to/component.wasm" }

The foo:bar@0.1.0 is pattern that says "for any imports in my component that are part of foo:bar@0.1.0 compose with matching exports from path/to/component.wasm".

As a developer what i'd really want to express while developing my application is:

[dependencies]
"bar" = { path = "path/to/component.wasm" }

Where bar here represents a name of my choosing that would appear in my languages bindings. In the case of rust, i'd be able to access the importized exports of my dependency via the bar module, e.g. use bar::....

What's lost here is the expressitivtiy and control on how exactly imports/exports are composed together. With this change we'd simply plug components into the main component in the order listed in the manifest. Having said that, i think plug-style composition is the more intuitive flavor of composition desired at the level of spin.

I'm opening this issue Pre-SIP to gather brainstorming feedback or perhaps alternative designs altogether!

[itowlson]

Am I right in thinking that, in your Rust example, bar becomes a module name around the imports e.g. if component.wasm exports alpha:beta/gamma and delta:epsilon/zeta then you would get a generated WIT like

world bar {
  export alpha:beta/gamma;
  export delta:epsilon/zeta;
}

a binding declaration like

mod bar {
  wit_bindgen::generate!("the-generated-wit");
}

and hence usage like

let omega = bar::delta::epsilon::zeta::unleash_the_krynoids();

kind of thing?

Or were you envisaging more flattening and renaming in the generated WITs?

[fibonacci1729]

Correct! With the caveat that, without poking too deep just yet, i'm not sure how bar is plumbed through to get that second code block mod bar { ... }. World names aren't generated in the bindings so we would need to figure out how to communicate bar through the wit i think.

[fibonacci1729]

we would need to figure out how to communicate bar through the wit i think.

After doing some digging, i'm not sure this will be possible. From what I can tell, wit-bindgen only generates code paths for packages that contain interfaces and we don't want to have to use interface names to force a developer chosen namespace (since these show up in the actual compiled component).

A (very hacky) alternative is to include a comment on the world root we synthesize during the creation of spin-dependencies.wit that we can consume when consuming the spin-dependencies.wit but that takes us scarily close to building wrapper tools for wit-bindgen for each language we'd like to target. In any case, it feels very fragile to communicate this developer chosen namespace through comments.

@tschneidereit did you have any more thoughts on how we might be able to achieve this?

[fibonacci1729]

Given ^ needs more brains/thought, I think we should go ahead with #3378 and if we come up with a more ergonomic dx for dependencies post 4.0 we can rev the manifest but for now i'd like to avoid sacrificing the gains of what #3378 offers in improving the experience in the near term.

cc/ @itowlson let's undraft #3378 and i'll give a final review so that we can merge and move on to the more interesting bits of the experience.

[fibonacci1729]

Closing this in favor of #3445