Modules & monorepo

[old nest]

You can use modules in monorepo. And you can have the Go SDK use the same go.mod as the parent repo

[cloud fern]

The place I imagine for dagger modules is probably more the multi-language aspect, so the local service in the repo can use the SDK in the language it's written in

I doubt that will happen in this case, we prefer consistency and everyone pretty much knows Go. Python and JS/TS are foreign to some of the developers

[old nest]

Once modules are GA (and properly polished), you can flip it around: containerized functions are the default, you only embed client calls in a custom tool if you have a specific need to do so.

Various integrations will assume you're starting from modules. Eg. various CI integrations will assume there's an entrypoint function to call, etc

It will be a widespread assumption that daggerized project = dagger module at the root of the project

[cloud fern]

hmm, not sure how that will work out for monorepos, at least the way we do monorepo

We have a script / tool at the root of the repo that is the core DX, the developers hardly use other tools directly. Make is probably #2

They don't invoke docker, go, etc directly

What I'm planning is more a single module that takes the directories to work on (with other args), rather than having a module per service

[old nest]

If you specifically want to write your own custom tool, that's a good reason to do it this way. You can still get the best of both worlds, by having the wrapper tool call an entrypoint module. That way both experiences are available. For example devs can call the custom tool, and your CI integration can be the stock Dagger-supplied YAML snippet - either way same module under the hood.

[cloud fern]

We have a Makefile per service, but the vision is to not have more things replicated all over the monorepo. It becomes a maintenance nightmare

We've been using CUE to create a software catalog. This allows the tooling to figure out the structure and nature of services and do the right thing, without developers having to think much about it

Dagger-supplied YAML snippet
There's a growing hate for yaml 🤣 but my vision is to turn CI into a single call to dagger. There are going to be some HW scaling issues if we go there though.

Is it possible to send some of the build pipeline to a GPU vs not?

Are modules a place where we can configure the underlying HW requirements needed to run a pipeline?

For example, we have 4 different types of Jenkins workers, 2 general purpose, 1 GPU, 1 super fast disk

[old nest]

There is experimental support for mounting gpus into your container. Container.WithGPU I think

But scheduling the job to the right machine based on available resources (gpu, cpu, io, ram) is not supported by dagger itself. You need to do that out of band. Typically you'd use your existing CI to do that, but you could use any scheduling system