We are working toward this goal, as natively supported: push to have codegen files committed (and used at runtime), migrating from dagger develop to dagger generate and generate functions will automatically come with built-in check. That to say what your doing will be the default way to deal with modules.

I'm happy to see that our ideas around codegen make sense for others too 🚀

With that, maybe we can simply not run the go mod tidy in more cases. Right now, during a develop the existing files are ignored. So we need to run tidy at some point. But with generated files handled, maybe this phase can simply be ignored at all. If there's a go.mod and go.sum then we don't run go mod tidy. And it's up to the module's developer to run it. As the files should all be generated, it's just a standard go module and so it doesn't make sense anymore to do something here. Except when we update the engine version roughly.
I have to check if there isn't cases we would like to run tidy, but if that make sense only the first init/develop might require it.

I completely agree! That make the codegen must closer to a go generate than a complex pipeline.

I think the first init/develop is good enough, and then we must make it easy to spot if a module won't run because go mod tidy is missing but normally it should raise a regular go error. Maybe test it on your branch @eunomie :)

Thanks both! Just wanted to also point out that my initial speculation for go mod tidy causing dependencies to be upgraded was incorrect, it's actually a go get -u that runs within the Dagger develop that is causing those. Is there any intention in keeping this behaviour when running develop?

That to say what your doing will be the default way to deal with modules.

Glad to hear that this will become a natively supported pattern though! It will simplify a lot of our existing infrastructure greatly.

Thanks both! Just wanted to also point out that my initial speculation for go mod tidy causing dependencies to be upgraded was incorrect, it's actually a go get -u that runs within the Dagger develop that is causing those. Is there any intention in keeping this behaviour when running develop?

We might be able to get the dagger package without dynamically add it to the module's code if we don't codegen at runtime because we would assume the go.mod of that module is right.
We could just add that package in the go.mod when running develop and let the user run tidy after that.

I think it would be good to assume that the go.mod is correct as is, seems like didn't cause many issues (that I'm aware of) in previous Dagger versions, but I could be wrong :)