Robin Brown (Dec 06 2022 at 15:41): Robin Brown (Dec 06 2022 at 15:41):As we're designing the client, I'd like a better idea of what a dependency solve for warg packaged components means for tools like cargo-component. If you have some base component with several dependencies, can they each be resolved independently including their transitives since wasm instantiation semantics allow there to be multiple versions of something at the same time in different places? or do tools like cargo-component want to select one version of a given package to use everywhere if possible? In the independent case, a "dependency solve" is just a recursive operation selecting the latest viable candidate for each dependency and then repeating on its dependencies. In the other case, it's a more complicated graph operation.
Robin Brown (Dec 06 2022 at 15:41):@Peter Huene @Luke Wagner @Lann Martin
Peter Huene (Dec 06 2022 at 16:22):I haven't thought about this too deeply yet, but I think a tool like cargo-component would be more geared towards asking the registry for worlds, interfaces, and, perhaps, the "type" of a specific component (for its default interface?) so that it can do bindings generation; the user's source builds against the bindings to produce a component that imports/exports instances only. that component can then be published to the registry and used by anything providing or expecting those interfaces.
I think it'd be in the domain of a tool like wasm-compose where you want to start providing the concrete implementations of the components that comprise your application. Then a registry might be the place to answer "find me a component (and its transitive dependencies) that satisfies _this_ component's instance imports"; how an answer to that question translates into a fully linked component that meets the requirements of users for deploying their application, I don't know. it sure seems like there'd still be a lot of manual specification by the user at composition time.
Peter Huene (Dec 06 2022 at 16:30):to be honest, i struggle with what a good DX is here given how flexible the component model is; we certainly could have one component depend on another directly and define/import that component in the locally produced component for instantiation when building with cargo-component, so it'd need a way of solving dependencies in that case
Luke Wagner (Dec 06 2022 at 17:28):Agreed that the flexibility of component linking raises hard DX questions. In the fully-general case, I think we'll want a proper linking language that exposes the full flexibility of linking in a more-ergonomic-than-wat manner. But I think there are also a bunch of specialized uses of linking where we can follow existing developer conventions and emit a subset of the full linking flexibility (which is fine; we don't have to expose the fullness of component-linking in these cases), and one such example is dep-solving via a traditional dependencies section in a build-config file like package.json or Cargo.toml. In this context, iiuc, the prevalent developer expectation is to share dependencies by default. The new opportunity we have is that when a traditional dep-solver would error out due to an unresolvable version conflict, our component-based dep-solve could resolve the conflict by creating multiple instances. One DX question is whether this is fully automatic and silent or do we think it might surprise the developer and so we want to require the developer to manually resolve the conflict by saying when/where/how to create multiple instances.
Last updated: Oct 23 2024 at 20:03 UTC