I think in your Articles / Tutorials you should show how to migrate(?) e.g. a "Hello World" Maven project running in GitLab CI to Earthly. This will help people understand it better (from a concept they're already familiar with).
Show HN: Earthly v0.6
21–30 of 38 posts
Re: Show HN: Earthly v0.6
#22I tried using Earthly, great product. Unfortunately, we rejected it at our organization due to how verbose the commands are. I want my users to be able to say `earthly plan-stage` for a terraform repo, and for it to work. But you cannot. You cannot have earthly automatically use environment variables from your env, you have to explicitly list the commands yourself using flags: $ earthly \ --build-arg AWS_ACCESS_KEY_I…
Interesting. Dev tools post always catch my attention. For me, your comment regarding `build-arg` is in the same bucket as the comment regarding the need for a `ls` command. Ultimately I predict that the requested feature set will eventually be equivalent to what is already in Bazel -- like `.bazelrc` for setting up build variations and environment variables, and `query` for figuring out what is going on with the project. If Bazel has been working on these features and issues for years, I'd expect the same here.
Earthly seems very useful to work around issues like cross-compiling. A simple example that I'd expect a lot of people to run into is running into libc/stdlibc++ differences with Alpine containers. That is easy to come across when doing something as simple as pulling in a Python pip dependency that wants to compile native C/C++ code. I find this extremely difficult to learn to do in Bazel.
However if you're in the league of complex cross-compiling, then you may already be on CMake and/or Bazel and have the dev resources to define the toolchains as needed.
Re: Show HN: Earthly v0.6
#23Earlier quoted context omitted.
What is your gripe with the Docker folks?
Docker's codebase is a mess, the implementation is a mess, the data formats are a mess, the performance is a mess, it deadlocks under pressure (at least it did several years ago when I worked at Vercel), and I don't like its recent power moves to monetize people already somewhat locked into Docker. Just my opinions.
But the dockerfile format has nothing to do with the docker codebase right? I run all my docker containers with podman (I recently moved over due to the monetization issues you mentioned), but I still use dockerfile format because they are (imo) good enough and also ubiquitous
Re: Show HN: Earthly v0.6
#24I think in your Articles / Tutorials you should show how to migrate(?) e.g. a "Hello World" Maven project running in GitLab CI to Earthly. This will help people understand it better (from a concept they're already familiar with).
Great suggestion! We have a walk-thru in the docs and some examples in GitHub.
https://docs.earthly.dev/basics
https://github.com/earthly/earthly/tree/main/examples
Do those help?
Re: Show HN: Earthly v0.6
#25Earlier quoted context omitted.
Docker's codebase is a mess, the implementation is a mess, the data formats are a mess, the performance is a mess, it deadlocks under pressure (at least it did several years ago when I worked at Vercel), and I don't like its recent power moves to monetize people already somewhat locked into Docker. Just my opinions.
But the dockerfile format has nothing to do with the docker codebase right? I run all my docker containers with podman (I recently moved over due to the monetization issues you mentioned), but I still use dockerfile format because they are (imo) good enough and also ubiquitous
The dockerfiles are technically specified by OCI but the Moby project has a lot of sway in that committee. The Dockerfile spec has a number of deficiencies in it that aren't being addressed. Until recently, Docker was the only fully supported, ubiquitous way to build container images from a Dockerfile. The file even being called a "Dockerfile" is, in my opinion, annoying too.
Podman of course allows `Containerfile` but meh. I just don't like the tight coupling of the Dockerfile spec and the Moby project, since I don't like the Moby (Docker) project for the reasons listed above.
Re: Show HN: Earthly v0.6
#26Why is it called "earthly"?
Re: Show HN: Earthly v0.6
#27Oh geez.
Dockerfiles are reason #1 for docker's popularity.
Shipping 'the lot' so the artifact works everywhere is #2. This is incredibly inefficient for most use cases.
`docker pull random-shit` is #3.
Everything else it gives is largely immaterial, or maybe even a negative.
You guys are solving #1 and #3, and providing a better alternative to #2. I'm very excited for you and your project!
Re: Show HN: Earthly v0.6
#28How does this differ from Mesos?
I saw that you were downvoted for asking a legitimate question. Can you expand on what you mean?
Having done a lot of work in the past with Mesos and Docker and having done the deep dive on Earthly I just don't see the corollary between Mesos and this. Maybe there's more context you can provide :)
Re: Show HN: Earthly v0.6
#29Earlier quoted context omitted.
It’s a build tool, I’d be surprised if something like it worked well for non build related tasks. I suspect bazel would be equally verbose (if not even worse or impossible). I think you’re better of using something like taskfile w/ earthly for a really good workflow, it gives you the best of both worlds. (Actually I think I saw this on their slack)
Yeah, that was what I was doing in the prototype stage. But then I thought "why do we need two task runners? " and ended up just going with task files. They sell it as a make replacement. Bazel constantly says "you don't need hazel, it is a big tool" and earthly does not. Which is fine. Either way, I already said earthly is a great tool. This is just my feedback around why it doesnt fit my use case.
Ah sorry, that’s fair. We went the other way from having just taskfile to having both and it seems quite nice so far.
Re: Show HN: Earthly v0.6
#30Earlier quoted context omitted.
Yeah, that was what I was doing in the prototype stage. But then I thought "why do we need two task runners? " and ended up just going with task files. They sell it as a make replacement. Bazel constantly says "you don't need hazel, it is a big tool" and earthly does not. Which is fine. Either way, I already said earthly is a great tool. This is just my feedback around why it doesnt fit my use case.
Ah sorry, that’s fair. We went the other way from having just taskfile to having both and it seems quite nice so far.
We may go back! Earthly is quite nice