4 ms·

I like nix. If you dig into nixpkgs far enough back you can find commits from me bumping version hashes on postgres. The caching and our future plans for distr

by agbell 5y ago

I like nix. If you dig into nixpkgs far enough back you can find commits from me bumping version hashes on postgres. The caching and our future plans for distributed builds have some similarities with Nix Hydra and Bazel but creating images in earthly is closer to docker multistage builds than it is to nix. We are not just for building docker images, though. In the real world a 'build' is more than just building an image. It will have linting, and tests and integration tests and maybe some services need to be stood up and tore down in between to make sure an api contract wasn't broken and you might need different binaries generated for different architectures and so on. I could be wrong but I think nix is focused more on just the producing the artifact part. I do love how they approach every build as a pure function though.

n3t 5y ago
It makes sense! Thank you for your response.
mikepurvis 5y ago
Nix does have some limited support for a "check" phase, but I think it's meant to be for an ultra-quick Homebrew style smoke test, basically just confirming that `thing-bin --version` writes to stdout and returns 0, rather than something usable for larger scope integration.
gravypod 5y ago
Do you plan on having some support for hermetic and reproducability? That's the main thing Bazel brings to the table and I'd like to see some solutions that can scale to hundreds of services like that
- agbell 5y ago
  I know less about Bazel then Vlad does so he may have a better answer. But Earthly lets you use your languages build tool and expects but does not enforce that the individual steps you call are reproducible. So it is a less granular approach than Bazel which we think offers a lot of same benefits but without guaranteed bit for bit reproducibility. You can do non-repeatable things in a `RUN` but if you don't then it works well and you get to use all your existing tooling rather than having to replace them.
joepie91_ 5y ago
> I could be wrong but I think nix is focused more on just the producing the artifact part. That is only true to a point. Nix has an extremely broad definition of what constitutes a "build", in practice, and this process can include things like tests. That having been said, there are undoubtedly certain tasks that Nix itself is not great at - but when you think of Nix more as a system primitive for expressing build processes rather than as a universal do-everything tool, that just means you would build tooling on top of it for those tasks, like Hydra does for CI for example. That way everybody wins; you don't need to reinvent the build orchestration parts of the process, it interoperates with the entire existing package set, and the broader Nix community gains a new tool that helps them solve their problems more effectively.

by agbell 5y ago

n3t 5y ago

It makes sense! Thank you for your response.

mikepurvis 5y ago

Nix does have some limited support for a "check" phase, but I think it's meant to be for an ultra-quick Homebrew style smoke test, basically just confirming that `thing-bin --version` writes to stdout and returns 0, rather than something usable for larger scope integration.

gravypod 5y ago

Do you plan on having some support for hermetic and reproducability? That's the main thing Bazel brings to the table and I'd like to see some solutions that can scale to hundreds of services like that

agbell 5y ago
I know less about Bazel then Vlad does so he may have a better answer. But Earthly lets you use your languages build tool and expects but does not enforce that the individual steps you call are reproducible. So it is a less granular approach than Bazel which we think offers a lot of same benefits but without guaranteed bit for bit reproducibility. You can do non-repeatable things in a `RUN` but if you don't then it works well and you get to use all your existing tooling rather than having to replace them.

joepie91_ 5y ago

> I could be wrong but I think nix is focused more on just the producing the artifact part. That is only true to a point. Nix has an extremely broad definition of what constitutes a "build", in practice, and this process can include things like tests. That having been said, there are undoubtedly certain tasks that Nix itself is not great at - but when you think of Nix more as a system primitive for expressing build processes rather than as a universal do-everything tool, that just means you would build tooling on top of it for those tasks, like Hydra does for CI for example. That way everybody wins; you don't need to reinvent the build orchestration parts of the process, it interoperates with the entire existing package set, and the broader Nix community gains a new tool that helps them solve their problems more effectively.