#sdk vendoring, library split

1 messages · Page 1 of 1 (latest)

tawny turtle
#

How will that works? I'm thinking about the introspection.json we receive from the codegen/module runtime perspective. Will the json be split in 2, one for the main library (no modules) and one for the module specificities? Or a single json but with flags to know what is specific or not (and by extension what needs to be generated)?

#

I'm also thinking about the main dagger client: right now all the other modules in dependencies are added to the main client. So for instance dag.wolfi(). It will not be part of the main library I guess.
But depending on the languages, it might be impossible to extend this type. By extend I mean to add more methods to the existing type. (something that is doable in ruby 🙂 )
We can have a client that will inherit from the library one, maybe that makes sense. And it might even be better to avoid confusion between default types and module specific ones.
(sorry, thinking out loud, maybe all that sounds obvious 😅 )

ornate heath
#

No need to split. My goal, for the longest time, is to create a dagger abstraction layer on top of the GraphQL introspection, for all codegen. This would be centralized. See https://github.com/dagger/dagger/issues/5226. It will simplify a lot the codegen code in all SDKs. They'll practically only need to focus on "presentation", or syntax translation. Actually, the initial plan was to base it off of the GraphQL schema, but now we have the TypeDef system, which includes more information like the originating module of a type.

#

I’m thinking it doesn’t necessarily have to be a split between the core API and module dependencies. It’s like the library comes with the core api, but the generated client bindings in a module could replace those entirely, if the library detects that it exists and switches to it internally.

#

I’ve prototyped this in Python already, without extending the Client type, like this:

try:
    from dagger.client.gen.root import *
except ImportError:
    from dagger.client._gen_placeholder import *

That makes it easier for languages that can’t extend the type, but may still be hard if they can’t dispatch to one type vs another at runtime. There could still be a solution, e.g., a plugin system or similar.