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.

▲

esafak 12 hours ago | parent | next [-]

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.

▲

mxey 10 hours ago | parent [-]

Dagger uses BuildKit. all your “imperative” code does it assemble a graph that’s gonna be executed by BuildKit in dependency order.

▲

Too 10 hours ago | parent | next [-]

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?

	▲	shykes 8 hours ago \| parent \| next [-]
		Dagger is a declarative DAG engine. So, yes, you can do that.
	▲	mxey 7 hours ago \| parent \| prev [-]
		There is an overhead per container launched so it would probably not be worth it.

▲

esafak 10 hours ago | parent | prev [-]

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.

▲

justincormack 12 hours ago | parent | prev [-]

Its not as fine grained as bazel/buck. That doesnt necessarily matter.