builtin container packages and module init performance

[tall hearth]

🧵

im about to replicate this situation by adding some engine-image-module-bundling for the typescript SDK, so im curious if there's been any previous discussion on the topic

maybe the intent is that when you tidy a module SDK's go.mods, you've gotta tidy the go SDK's and all the other module SDKs?

[tall hearth]

for science https://github.com/dagger/dagger/pull/9565

https://github.com/dagger/dagger/pull/8761 is where the go thing was introduced, @harsh harbor , did you have plots for how to manage the versions of the go modules we bundle?

[harsh harbor]

Yeah it's a bit buried but we actually use the go sdk's go.mod to bootstrap user modules https://github.com/sipsma/dagger/blob/8ee2e78ca6609ec074f680579c5d0c59916e2c7d/cmd/codegen/generator/go/generator.go#L263-L263

So that helps keep newly init'd mods in sync, though I forget if/how we require updates to versions in user module go.mods so that they continue to match (cc Alex, Justin if either of you remember, I forget how to silent ping)

[tall tide]

(it's @silent somewhere in the message, and it's a silent ping)

[tall tide]

we update user go.mods to be at least the dagger version i think

https://github.com/dagger/dagger/blob/115a4552ed99de13db32aeee1de875490995eca6/cmd/codegen/generator/go/generator.go#L271-L280

[tall hearth]

this is what i was looking for, thank you

or at least that answers how we keep users' modules relatively cache-hitty... it doesn't answer how we keep the go sdk's go.mods updated

[harsh harbor]

We just keep this one updated: https://github.com/sipsma/dagger/blob/9d1d06a92234b449162cd0ff3cda689153fcf67d/sdk/go/go.mod#L1-L1

That's the one that's embedded, mentioned here #1338997699214839809 message

[tall hearth]

ah nice, i can see in the blame dependabot does watch it and justin merges its bumps 🙂