CPcpuguy83·Mar 19, 2024
I'm not talking about OCI images (again, that's the _output_).
I'm talking about how they are built.
OCI images are OCI images, they get extracted the same way no matter if there's conflicting paths or not.
What I'm saying here through multiple different threads is, buildkit and nix build things the same way.
`docker build` is not just a Dockerfile builder, its actually a grpc service (with services running on both the docker CLI and in the daemon).
This service is actually very generic.
It includes builtin support for Dockerfiles, which just converts the Dockerfile format into what buildkit calls "LLB", which is analogous to LLVM IR.
What I'm also saying is, people are comparing "docker build" with a Dockerfile that's using a package manager that's not even provided by docker to nix.
This is not an apples to apples comparison, and in fac
Read the rest
t you can implement nix packaging using buildkit (https://github.com/reproducible-containers/buildkit-nix).
I'm also saying that `Dockerfile` does actually support merging dependencies without being order dependent (this is `COPY --link`).
But also, you can drive buildkit operations without going through Dockerfile. You can also plug in your own format with the `syntax=<some/image>` at the top of your file.
This isn't "convert to dockerfile", its "convert to LLB", which is all the Dockerfile frontend does.
Finally, I'm saying nix isn't in and of itself some magic tool to have a reproducible build.
You still have to account for all the same things.
What it does do, at a package management level, is make it easier to not have dependencies that change automatically over time (which has its own plusses and minuses).