#Hey Erik,

1 messages · Page 1 of 1 (latest)

tawny bronze
#

But, at the moment, for example, is it impossible for any of the functions of supergit to return another module referenced on the daggerverse, as my Cargo type declared in my other cargo module ?
Yeah when it comes to types used for Function args and for Function returns, a module can only use either its own types or types from the core API (like Directory, Container, etc.)

The reason you can't use types from other modules is that it would create dependency hell problems. Some more details here if interested: https://github.com/dagger/dagger/pull/6102#issuecomment-1813209934

I've read a bit your interface PR, and am trying to understand the impact on the index presentation this will have on the Daggerverse (to anticipate, and if necessary).
From client perspectives, interfaces are essentially the same as objects. They are just a set of functions that can be called.

The main place the difference between an interface and object is most noticeable is when authoring modules. But you shouldn't need to worry about that for your effort if i understand correctly.

I am also a bit confused on how a dagger call module-with-interface CLI exec looks like. Does that work atm, like can I already hack some stuff and execute those interfaced modules on the CLI, to see the behavior / patterns ?
Yeah interfaces work in the CLI, they end up being presented in the exact same way objects are

From what I grasped, this won't have much impact: users will continue to not be able to return another module type. And, on the contrary, the interfaces available for interoperability will be available in the module schema: instead of having the schema as of now, we will have, for a given schema, a few other objects representing all the interfaces available / or all the interfaces used ?
Yeah when authoring modules, you still can't use objects from other modules as function args/returns.

What you can do instead is define an interface in your module and use that as an function arg/return.

So supergit couldn't return a Cargo object, but it could define an interface for the functionality of the Cargo object it wants to return and then return that instead.

Or for another example, supergit still can't accept a Cargo object as an function arg, but it can define an interface for what it wants from the Cargo object and use that interface as the arg type instead.

The reason this avoids the dependency hell problem is that keeps the types exposed by a given module confined to just the types it defines, not types from its own transitive dependencies (which is where the gates of hell open). The interface type is defined in a module (not a dependency) even though it can in practice end up being implemented by any other object from any other module.

#

Let me know if that's helpful and if you try using all this how it goes! It's a very MVP feature so will be good to get feedback early on from the real world 😄

runic plover
#

@raven crown I’m excited that you’re looking at my module, and happy to adapt it to make your use case work 😁 What integration do you have in mind?

raven crown