#where is dag. defined?

1 messages · Page 1 of 1 (latest)

summer nacelle
#

Dagger generates definitions for you. If you're using the latest version of dagger, call dagger ddevelop at any time to generate them. Then your IDE should be happy

steep quartz
#

I wasn't able to get this command to work, there were also an error in the code from dagger init --sdk=go

dagger.io/dagger was not imported, nor was Container prefixed with the package name at the point of usage

burnt needle
#

that's expected; each module gets its own generated client, and doesn't import dagger.io/dagger

#

what was the output of dagger develop?

steep quartz
#

Is there any way to avoid the extra go.mod & 7000+ lines of generated code being committed to git for every place we need to create/use a module?

#

We used to have multiple go.mod files, but have changed it to just a single one for the entire monorepo.

burnt needle
# steep quartz Is there any way to avoid the extra go.mod & 7000+ lines of generated code being...

You can .gitignore the generated file if you want to since we always run codegen just-in-time. We used to do that by default but backed out since without the generated code CI lints/etc. break (assuming you have that configured repo-wide).

Not 100% sure about the go.mod situation, this all changed recently and I haven't had a chance to try that in the new model yet. Context here: https://github.com/dagger/dagger/pull/6575 - the first thing I would try to do is just delete it, and see if it's able to discover the parent one (that might "just work")

steep quartz
#

Does it take the full repo as context or just the working directory? What happens if we use shared libraries from a directory outside of the dagger module, but within our monorepo?

burnt needle
#

It does its best to avoid loading the whole repo; by default it only loads **/go.mod and a few other Go-specific paths, but you can configure explicit include/exclude globs in dagger.json ({"include":["foo"]})