4 ms·

Can anyone who's familiar with Earthly explain why somebody would want to use it instead of Bazel?

netvarun 5y ago
Same question here too!
oftenwrong 5y ago
I had the same thought, and found this: https://github.com/earthly/earthly#how-is-earthly-different-from-bazel https://github.com/earthly/earthly#how-is-earthly-different-...
thundergolfer 5y ago
The best summary from them looks to be: > Overall, compared to Bazel, Earthly sacrifices some correctness and reproducibility in favor of significantly better usability and composability with existing open-source technologies Exactly how much correctness is getting sacrificed is pretty important. A key insight of Bazel is that you can’t have speed at scale without correctness. Would be good to have Earthly described within the framework of “Build Systems a la Carte”.
no_circuit 5y ago
I don't think it is meant to replace any particular build system like Bazel or make. Rather it is a better dependency glue flavor for Docker image building and testing. Earthly uses Makefile-like targets which can be leveraged through more advanced references [0]... essentially can replace plain "copy --from=" with a new magic strings syntax which also understand git. Build systems like Bazel would be invoked within a container. I don't think the "why" using it instead of Bazel (and its plugins) will become clear until the Earthly SaaS gets announced that is hinted about in their TOS [1]. Build resource pool management, image release management, testing/dev environment definitions, custom URLs to test pull requests as seen elsewhere? Arguably one could say they'd probably be able do the same thing by writing some Skylark and use remote build execution, but that could be close to saying Dropbox wasn't special in a Show HN thread. :-) [0] https://docs.earthly.dev/docs/guides/target-ref https://docs.earthly.dev/docs/guides/target-ref [1] https://earthly.dev/tos https://earthly.dev/tos
stonewareslord 5y ago
I use earthly. I would not use it instead of bazel, but with bazel. You can imagine earthly working by building a DAG of docker commands (RUN, ENV, ...), similar to how bazel/make make one on your source files. If A depends on B and B changes, B then A are built, etc. So keep bazel for building and testing, but you can use earthly to run above it so every bazel build is in a fresh docker container. Example: # All image deps RUN apt install -y bazel gcc build: RUN bazel build test: FROM +build RUN bazel test release: FROM +build RUN bazel package SAVE ARTIFACT AS LOCAL ./a.out a.out SAVE IMAGE cool-app:latest Basel build runs before the other two targets, but testing and packaging run in parallel. I do this for elixir projects -- npm install assets and mix deps.get in parallel, then copy both results into the final image. Edit: you can also inject arguments and the dependency graph will fork when needed. So for example, I can specify multiple version targets and earthly will only start running in parallel when it hits the build arg line (since subsequent run lines will have different build arguments)

Same question here too!

I had the same thought, and found this: https://github.com/earthly/earthly#how-is-earthly-different-from-bazel https://github.com/earthly/earthly#how-is-earthly-different-...

thundergolfer 5y ago

The best summary from them looks to be: > Overall, compared to Bazel, Earthly sacrifices some correctness and reproducibility in favor of significantly better usability and composability with existing open-source technologies Exactly how much correctness is getting sacrificed is pretty important. A key insight of Bazel is that you can’t have speed at scale without correctness. Would be good to have Earthly described within the framework of “Build Systems a la Carte”.

no_circuit 5y ago

I don't think it is meant to replace any particular build system like Bazel or make. Rather it is a better dependency glue flavor for Docker image building and testing. Earthly uses Makefile-like targets which can be leveraged through more advanced references [0]... essentially can replace plain "copy --from=" with a new magic strings syntax which also understand git. Build systems like Bazel would be invoked within a container. I don't think the "why" using it instead of Bazel (and its plugins) will become clear until the Earthly SaaS gets announced that is hinted about in their TOS [1]. Build resource pool management, image release management, testing/dev environment definitions, custom URLs to test pull requests as seen elsewhere? Arguably one could say they'd probably be able do the same thing by writing some Skylark and use remote build execution, but that could be close to saying Dropbox wasn't special in a Show HN thread. :-) [0] https://docs.earthly.dev/docs/guides/target-ref https://docs.earthly.dev/docs/guides/target-ref [1] https://earthly.dev/tos https://earthly.dev/tos

stonewareslord 5y ago

I use earthly. I would not use it instead of bazel, but with bazel. You can imagine earthly working by building a DAG of docker commands (RUN, ENV, ...), similar to how bazel/make make one on your source files. If A depends on B and B changes, B then A are built, etc. So keep bazel for building and testing, but you can use earthly to run above it so every bazel build is in a fresh docker container. Example: # All image deps RUN apt install -y bazel gcc build: RUN bazel build test: FROM +build RUN bazel test release: FROM +build RUN bazel package SAVE ARTIFACT AS LOCAL ./a.out a.out SAVE IMAGE cool-app:latest Basel build runs before the other two targets, but testing and packaging run in parallel. I do this for elixir projects -- npm install assets and mix deps.get in parallel, then copy both results into the final image. Edit: you can also inject arguments and the dependency graph will fork when needed. So for example, I can specify multiple version targets and earthly will only start running in parallel when it hits the build arg line (since subsequent run lines will have different build arguments)