Implementation of Component Dependencies

[fibonacci1729]

This PR implements the Component Dependencies SIP.

See here for a simple example.

There are a few remaining items to address, namely better error messages and some lingering documentation TODOs. Additionally i'd like to put a few examples together.

[rylev]

Looking like a really great start! 🎉

[itowlson]

A few random and not very organised comments - I hope it's not too early for them, feel free to ignore if it is! I'm very much enjoying playing with the new feature. Pretty slick!

[rylev]

Looking good! I'm fine with merging as is.

I do have one piece of feedback about the user experience, that I'd like to discuss. In the spin.toml manifest, the component dependencies keys are somewhat treated like patterns where a "org:package" = { path = "/path/to/wasm.wasm" } means that all imports that have "org:package" as their org/package namespace will be satisfied by that dependency. I wonder if we would be better of with a more explicit pattern matching syntax like "org:package/*" = { path = "/path/to/wasm.wasm" }. Such a syntax seems more extensible and less likely to paint us into design corners in the future.

[fibonacci1729]

I've been thinking about this over the last week and i'm not really sold that .../* is really all that more intuitive over what we have. Personally having multiple syntaxes to imply variabilitiy (e.g. .../* and no version to imply any-version) is a bit confusing. As a dev, if i saw foo:bar/* to mean "any interface" i would intuitively think that i would need to say foo:bar/*@* to imply any interface and version. @rylev i know this isn't a super strong argument against but i think i'd like to land this with the syntax as-is unless you really feel strongly.

[itowlson]

Thanks @fibonacci1729 for making this happen!

[itowlson]

I did have one further (extremely non-blocking) question on the deny-all adapter. The adapter Wasm file is checked in. But I am nut sure how it gets built. Is this a "build locally and check in the binary" thing? If so it would be good to investigate (as a follow-up) how to move it to a controlled, trusted build environment, but I am not sure how that would play nicely with needing to have it checked in and being included as a blob.

[rylev]

I've been thinking about this over the last week and i'm not really sold that .../* is really all that more intuitive over what we have.

@fibonacci1729 I'm not tied to my proposed syntax, but I do maintain that the current syntax is not ideal. The fact that "org:package/interface" means a specific interface while"org:package"` means any interface seems inconsistent, and if you had asked me to guess what the syntax would be, I would have guessed that. What's more, the current syntax doesn't seem to be very extensible. For example, how would we imagine a syntax for specifying a list of interfaces?

I'm not tied to any particular solution, but I feel somewhat strongly that the existing syntax is the wrong way go.

In the interest of making some sort of alternative for discussion, how about:

# A specific interface
"org:package" = { interface = "my-interface", path = "path/to/component.wasm" }
# All interfaces is the default
"org:package" = {  path = "path/to/component.wasm" }

In the above syntax, the key is always the package.

[lann]

how would we imagine a syntax for specifying a list of interfaces?

# equivalent to "org:package/my-interface"
"org:package" = { exports = ["my-interface"], ... }

[fibonacci1729]

@rylev could you say more about why org:package/interface meaning a specific interface while org:package meaning a set of interfaces seems inconsistent? If you're concerned about enabling a more granular control over which interfaces can be matched, what @lann suggested is what we've been planning for in a follow-up iteration. Currently the code enforces a constraint to prevent this where it checks that if a dependency name is in the package pattern form the dependency object (right-hand-side) cannot specify an export. In the future it would seem to make sense to allow saying "org:package" = { ..., exports = ["a", "b"] } to mean that for all compatible imports part of the org:package package use a and b to satisfy them.

[itowlson]

Regarding the UI, my mental model was that the left hand side was "the thing that is being satisfied" and the right hand side was "the thing that satisfies it". I appreciate that Ryan's "org:package" = { interface = "..." } idea was intended to spark new thinking, but for me the specific detail of putting "the interface that is being satisfied" on the right hand side feels a bit awkward. But maybe my mental model is out of sync with the realities of components? It wouldn't be the first time!

(And if Lann's comment is how we plan to do multiple interfaces then Ryan's idea seems consistent with it, although perhaps I am misunderstanding.)