News for hackers. Stuff that matters.
Re:Dagger: Define software delivery workflows and dev enviro... by jiehong on Sunday December 14, 2025 @08:00AM (#46262711)
Anybody used it?

Without the LLM bits, this is basically like Bazel or buck2, right?

Re:Dagger: Define software delivery workflows and dev enviro... by esafak on Sunday December 14, 2025 @08:21AM (#46262830)
No, it's code based CI/CD not a build system.
Re:Dagger: Define software delivery workflows and dev enviro... by ndrpnt on Sunday December 14, 2025 @08:34AM (#46262903)
I'd say it's somewhere in between. Sure it's marketed in the CI space, but to me the selling point of Dagger is not so much "write your GitHub workflows/GitLab CI in JavaScript" but "local exec, sandboxing, determinism, and fine-grained (remote) caching for mere mortals". So comparing it to Bazel/Buck2 is reasonable.
Re:Dagger: Define software delivery workflows and dev enviro... by esafak on Sunday December 14, 2025 @08:36AM (#46262914)
I wouldn't because build systems like Bazel are declarative and dagger is imperative. I accidentally created a build system in dagger and saw the difference; the code based way was highly branched, and thus unwieldy. I think you would want to call bazel from dagger to handle the build step.
Re:Dagger: Define software delivery workflows and dev enviro... by mxey on Sunday December 14, 2025 @10:15AM (#46263616)
Dagger uses BuildKit. all your “imperative” code does it assemble a graph that’s gonna be executed by BuildKit in dependency order.
Re:Dagger: Define software delivery workflows and dev enviro... by Too on Sunday December 14, 2025 @11:12AM (#46264087)
But that dependency order is usually just one big blob of ”COPY src/ . + RUN make”, within that block you have none of the benefits. Bazel/Buck has much finer awareness down to every individual file.

Out of curiosity, would it be feasible to take a big cmake project and generate thousands of compile rules into dagger and use it as a substitute for make with sandboxing? I’ve never seen builkit used with such many nodes, how would it fare?

Re:Dagger: Define software delivery workflows and dev enviro... by shykes on Sunday December 14, 2025 @12:39PM (#46264968)
Dagger is a declarative DAG engine. So, yes, you can do that.
Re:Dagger: Define software delivery workflows and dev enviro... by mxey on Sunday December 14, 2025 @01:16PM (#46265346)
There is an overhead per container launched so it would probably not be worth it.
Re:Dagger: Define software delivery workflows and dev enviro... by esafak on Sunday December 14, 2025 @10:18AM (#46263640)
Yes, but that does not help you build declaratively in dagger, does it? I would like to see an example of how to do so, if you have one.
Re:Dagger: Define software delivery workflows and dev enviro... by justincormack on Sunday December 14, 2025 @09:04AM (#46263044)
Its not as fine grained as bazel/buck. That doesnt necessarily matter.
Re:Dagger: Define software delivery workflows and dev enviro... by elryry on Sunday December 14, 2025 @08:38AM (#46262927)
Yeah, it's more like a .NET Aspire
Re:Dagger: Define software delivery workflows and dev enviro... by lowmagnet on Sunday December 14, 2025 @08:40AM (#46262933)
I use it to do builds in our monorepo. We got onboard before the LLM trash features. The base design is ok but there's things I'd do different today if I knew the build stuff would fade away for the LLM push.
Re:Dagger: Define software delivery workflows and dev enviro... by dilyevsky on Sunday December 14, 2025 @12:45PM (#46265031)
Works fine for us for glueing a bunch of CI steps together which would've been a pile of bash otherwise. Works well with depot.dev caches. We don't use it for anything AI either.
Re:Dagger: Define software delivery workflows and dev enviro... by kylegalbraith on Sunday December 14, 2025 @12:52PM (#46265106)
Founder of Depot here! Glad to hear it’s working for you all. Always happy to help expand things or make things better if you ever have ideas.