It would seem you don't understand how either work. They are basically opposites in how they actually work.
Docker layers are completely independent from each other. A docker layer is a sha256 sum of that layer. Separately there is an image manifest, which is also fetched with a sha256 of that manifest, states the order of the layers and at runtime those layers are stacked up on each other.
With docker, there is no explicit dependency chain. A layer is just a tarball or some JSON. Some tooling can take advantage of this fact. How nix builds docker images takes advantage of this.
Nix on the other hand, the output hash is not tied to the output hash, because the output hash is irrelevant to how it was produced. You also cannot know in advance the output hash of something. IE. If I do say "echo foo > bar.txt", I cannot know the sha256 sum of bar.txt until the code runs. But before the code runs I can know the hash all the inputs that will create bar.txt.
This fundamental difference means two builds, executing the same code can share the outputs. Provided that the build environment is trust worthy.
You are describing the makeup of an OCI image, which is the _output_ of a typical docker build (and also the output of the nix image builder).
While docker build can/does output OCI images, that is only an output.
How that output comes to be is not the output itself, same as the nix side the article is talking about.
> How that output comes to be is not the output itself, same as the nix side the article is talking about.
I see the confusion now. The nix image builders OCI layer's contents are _only_ nix store paths which _do_ include the input.
Nix store paths are are guaranteed to never overlap each other, and such the order of layering them in the docker manifest does not matter. But the docker layers are just tar balls of nix store paths. Each layer in the image has no dependence on previous or future layers at all. It is just one or more nix store paths.
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 fact 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).
Docker layers are completely independent from each other. A docker layer is a sha256 sum of that layer. Separately there is an image manifest, which is also fetched with a sha256 of that manifest, states the order of the layers and at runtime those layers are stacked up on each other.
With docker, there is no explicit dependency chain. A layer is just a tarball or some JSON. Some tooling can take advantage of this fact. How nix builds docker images takes advantage of this.
Nix on the other hand, the output hash is not tied to the output hash, because the output hash is irrelevant to how it was produced. You also cannot know in advance the output hash of something. IE. If I do say "echo foo > bar.txt", I cannot know the sha256 sum of bar.txt until the code runs. But before the code runs I can know the hash all the inputs that will create bar.txt.
This fundamental difference means two builds, executing the same code can share the outputs. Provided that the build environment is trust worthy.