Hear hear! Building bona-fide compilers that have interesting concepts, or just for fun, is a worthwhile thing to do. But these one-off languages are becoming ridiculous.
* buildah shows just how much of a headache Dockerfiles are. We already have a whole ecosystem of awesome scripting languages, such as bash, fish, zx, etc. Instead, we have to deal with the incredibly constrained (and harmfully magic) behavior of docker build.
* the whole implerative YAML ecosystem. I have been playing around with Dagger (CUE, a language built to solve real problems), and what a joy compared implerative CI.
I agree that Dockerfile has some constraints, but I'm not sure I get the "magic" part.
It's also not like it's a full language.
Run a command, set an env var.
There's some additional flags to set for optimizations.
Otherwise minimal things to get you to an env in a container that you can do whatever you want.
Also +1 to dagger+cue. I like that it gives me essentially for full power in buildkit's llb exposed as cue configs.
my.tar contains files owned by user 0, I want them to be owned by nobody:
USER nobody
ADD --chown nobody:nobody my.tar /app
Damn, --chown does not work when untaring and doesn't fail either but the files end up being owned by root. Fine, I'll just chmod
USER nobody
ADD my.tar /app
RUN chmod -R nobody:nobody /app
Now it fails (of course) because the files are owned by root and the command is ran as nobody.
While it all makes sense, I'm not sure why it's logic to have the ADD command always run as root and the others following the USER directive (yeah and I know, it's all my bad for using ADD rather then COPY)
Ah well, no I did not know, thanks :) in my case it's not too bad because I use kaniko's option to make a single layer of my changes, but good to know.
The problem I was trying to solve was container signing, as well as building AMD64+ARM64 multi-arch images without buildx having access to both contexts, i.e. on different VMs (a CircleCI limitation). When you use buildah without bud you learn just how many implicit steps are involved in a Dockerfile, and how those implicit steps have been the problem all along.
buildx works great when you're on the razor thin happy path. The abstraction is great for the majority who need it but, crucially, Dockerfiles provide no way to escape the abstractions.
> Hear hear! Building bona-fide compilers that have interesting concepts, or just for fun, is a worthwhile thing to do. But these one-off languages are becoming ridiculous.
I don't understand this mentality. Some programmers enjoy writing programs and some enjoy learning about programming languages. No one is telling all programmers they they need to learn about every programming language, but why paint the whole endeavor as frivolous?
I've been a sysadmin (now, devops, SRE, whatever) for over 15 years now, so when you say:
> No one is telling all programmers they they need to learn about every programming language
I cringe a little.
There are about 25 different DSL's in my head from configuring various desired state configuration systems or services which use DSLs, there's countless config file formats ranging for ZONE files to TOML to YAML to HCL and on and on and on.
DevOps of Yore had to know bash and perl, then it was Ruby, then python, now Go. The treadmill continues, it's _necessary_ to learn those things because you _must_ interact with those things.
That's before we get into special languages like AWK which had significant prominence when I was beginning life as a sysadmin too.
Nobody is forcing programmers to know every language, but honestly, there's a lot that sysadmins had to learn, and with the rise of DevOps, developers are the SysAdmins of tomorrow: so you have to know what we knew.
But I don't understand why you'd say it'd make you cringe.
You can have a discussion about how the industry (usually motivated by non-technical reasons) is moving towards. I was talking specifically about those "one-off" languages that some people find fun to investigate and/or work on.
Hear hear! Building bona-fide compilers that have interesting concepts, or just for fun, is a worthwhile thing to do. But these one-off languages are becoming ridiculous.
* buildah shows just how much of a headache Dockerfiles are. We already have a whole ecosystem of awesome scripting languages, such as bash, fish, zx, etc. Instead, we have to deal with the incredibly constrained (and harmfully magic) behavior of docker build.
* the whole implerative YAML ecosystem. I have been playing around with Dagger (CUE, a language built to solve real problems), and what a joy compared implerative CI.
* lest we forget how JavaScript came to be: https://thenewstack.io/brendan-eich-on-creating-javascript-i...