@Erik Sipsma @vito @al how do you feel

[frail bramble]

🧵

It's tied to the need to let other clients (non-modules) benefit from generated clients. I'm picturing that like a CLI command that drops a generated directory for you to save somewhere in your codebase, and then import locally. Seems cleanest.

[sharp spire]

But you're supposed to ignore this directory no?

[frail bramble]

My thinking is, if external clients get that, then why can't I get that too for my module

[sharp spire]

How are you managing that in a project that isn't using module? They will need to push these files

[frail bramble]

Good question, I think they would be responsible for managing these files. Either committing them or not, both are possible (and it's configurable today even for modules)

But the main difference is that, if the project is not a dagger module, then the Dagger CLI can't manage it end-to-end, which means we can't rely on the Dagger SDK to take over a whole directory and create/modify files at will

Also - mixing the generated client library with the software incluiding it (whether that's a dagger module or not) mixes all dependencies together. So when I have a module with no dependencies, it's weird that my go.sum suddenly is full of dependencies like otel etc, brought by the generated client

Of course one downside of unmixing, is that I wouldn't get the cool shortcut types. My code would get a little more verbose, because everything would be prefixed with dagger. or whatever I call my package. dagger.Directory, dagger.Container, etc

[sharp spire]

Yeah but this is another issue, IMO we shouldn't mix software deps with Dagger deps in the context of module.
It creates issues in both directions, like if you have private deps in your soft, you will have issues using the Dagger Go SDK because it will try to download these deps & fail

[silk summit]

I think only Go mixes in some generated code with the user code. It actually is just a minimal set with most of the generated code living under internal/ but is still needs to be in the same package at the moment because:

1. it allows go code to just typed *Container rather than *<package>.Container.
   • We could change this but, besides being breaking, IIRC the go autoimporter becomes extremely annoying and often start importing the wrong package.
2. The module code is a main func and thus we need some generated code to be in the same package as where users are implementing their module. This fixable in various ways, but a significant chunk of work + complication

So, yes it's very doable, but pretty far from straightforward.

For the whole idea of being able to use this to give non-module clients bindings to modules, I don't think this would be neccessary. The real meat of the bindings is already a separate package under internal/. The main impediment left is that we need modules to get automatically loaded into the engine when you use these generated bindings. I made some very preliminary headway on that a while back before various other things took precedence.

[frail bramble]

I see. Is the idea that the bindings would include something like dagger.Connect(ConnectOpts{Modules: generatedListOfModulesToLoad}) ?

Aside from the real meat, you'd still need a command like dagger sdk generate [-o TARGET] or something like that, right?

[silk summit]

The approach I was experimenting with was an init() func in go that did the loading when the package was imported. Would need similar things for other SDKs though, so still an open question in terms of the least-overhead-while-maximally-easy-to-use approach.

[silk summit]

Yes exactly, would need a slight variation on our current codegen and associated UX

[frail bramble]

Would we ever want to generate a different client library for each dependency? Or always a single library with all dependencies mixed together?