hello 👋 my name is Chris and I'm a site

[golden cypress]

Welcome! Thanks for joining us 🙂

If I build a bunch of Dagger pipelines in Go, is there a way to compile and ship them as a single binary? We're looking for ways to make installation/distribution for multiple repos/services super simple

This is technically possible but not the recommended approach. It comes down to the difference between using dagger modules and not.

Dagger modules are portable, cross language, and allow you to easily create nice reusable building blocks.

The tradeoff is that you are writing go that is going to be "interpreted" by the dagger engine.

Are Dagger pipelines flexible enough to apply the same pipeline(s) to multiple services? We have a few cases of multiple repos having multiple services and we want to support a default/shared functionality for common tasks like test, build, deploy, etc., for each service but still have the option to override/customize as needed (e.g. for deploy, one service might push a Docker image to AWS ECS, another might push compiled JS to S3 and bust some cache at the edge, etc.)

Yes, if you use modules! 😄

If you are up for it, i'd love to find some time and show you a demo where we can look at both approaches and discuss the pros and cons.

[warm lagoon]

thanks for the thorough answer! what does it look like to use Dagger modules vs. not? are modules the thing that goes into the Daggerverse? sort of like packages that can be reused/installed?

[golden cypress]

Yeah exactly!

Right now it comes down to dagger run vs dagger call

Our highly recommended approach is to use dagger modules and call them with dagger call

Modules can go in the daggerverse, but they can also be private repos as well. The benefit of modules is that they can be installed with the CLI dagger install, called locally and remotely dagger call -m github.com/my/modules and most importantly each time you write a function you get a CLI and docs for free.

--

On the other hand, dagger run / no CLI allows you to write regular go code using the go SDK, but in this world you are responsible for creating your own dagger client, you can build a custom CLI if you want, and you dont get any of the DX stuff

--

Modules are new, you used to always have to do it using Option 2 (dagger run). Option 2 will always be around but at this point its really designed for building a completely custom tooling. Modules are built on top of the technology here.

Right now these two approaches do not work that great together, we aim to improve that in the future though. (https://github.com/dagger/dagger/issues/5993)

Please note that we are still working on making our documentation include both approaches. Right now the docs are heavily biased toward modules. But you can see the old approach here if you are interested: https://archive.docs.dagger.io/0.9/

[warm lagoon]

oh interesting, thanks for all of this

[golden cypress]

My pleasure, happy to help. I'm around next week if you wanted to look into things a bit more together!

[round robin]

hello!
i am just coming back to dagger.
i am not able to find the docs on how to install private dagger modules by adding them to dagger.json

if there are docs / links, i might have missed them.
if you're able to point me the right way, really appreciate it.

[round robin]

sorry, i realized i was using the incorrect version.