Dockerfiles are imperative and the order of steps changes the container image that ultimately gets built.
Nix packages are declarative and idempotent. Everything is based on a functional package manager and when you configure your container via nix you get the same thing every time and can easily mix and match other packages and dependencies.
A contrived example is you have a program that depends on multiple versions of python, because nix does not globally set dependencies rather links them locally you can have both with versions of python without any conflicts
Containers built from Dockerfiles are difficult to exactly reproduce too. A very common practice is to update the package manager in which depending on what the server returns will be different from one day to the next where as nix hash addresses and builds from source everything (you can use caches to speed this up) and you get the same thing every time.
Note: NixOS isn’t perfect in terms of being purely functional as many package builds use scripts in pearl,bash,etc but from my understanding these are usually source specific reproducibility issues with Building particular packages and generally speaking things works as expected.
The declarative and idempotent container specification seems like a nice developer QOL improvement over docker but...
> Containers built from Dockerfiles are difficult to exactly reproduce
This isn't true in my experience, at least for a level of exactness that could have an impact on the behavior of the software running in the container. I have been working with docker in various contexts for 5 years and have never experienced any issues related to reproducibility (which is pretty much the primary selling point of docker). To your point though, I can see how reproducibility issues could happen in theory, but since its not a problem in practice it doesn't make for a very compelling reason to try nix instead. Just to be clear, I'm not trying to disparage nix, it honestly sounds pretty interesting, especially as a way to automatically provision a local workstation (docker is not good at this), but I am still curious as to the practical tradeoffs in terms of nix vs docker as a tool for building containers.
Then have your Dockerfile build from source. Many of the public layers that people build their containers upon do that for that exact reason.
If NixOS is only "generally speaking" correct because of the order it runs its scripts, then put it in a Docker container, where the whole point is to perfectly reproduce the order you run your scripts in order to minimize the errors that arise from doing otherwise. Still worried? That's why layers exist, so that every step you run you now have a static binary that you know will never shift under you, and that you can keep on building on top of.
In practice, building Dockerfiles is unreliable and can produce errors because they inherit all of the deficiencies of aptitude, python packaging, javascript packaging, et al.
In practice, building nix dependencies is reliable and reproducible because of the militant isolation of build environments, hash integrity checks on _all_ inputs, explicit dependencies, and the long tail of bug fixes related to non-determinism in unix tooling.
That's a great a vote of confidence. I would've thought that nix would only manage packages on the OS-level. How does it re-implement pip to be reliable? I currently have to stage a couple of `apt-gets` and `pip installs` before my `pip install requirements`, and it took a couple of tries to lock in the right sequence that worked. How does nix solve those problems?
Ha! I did this but the containers end up being somewhat large since you have all the NixOS package stuff in the container too.
However, building the container from a configuration.nix file gives you exactly what you need in the container and nothing more. It's like basing your container from scratch in a Dockerfile and copying only the needed compiled dependencies and nothing more into the container.
Nix packages are declarative and idempotent. Everything is based on a functional package manager and when you configure your container via nix you get the same thing every time and can easily mix and match other packages and dependencies.
A contrived example is you have a program that depends on multiple versions of python, because nix does not globally set dependencies rather links them locally you can have both with versions of python without any conflicts
Containers built from Dockerfiles are difficult to exactly reproduce too. A very common practice is to update the package manager in which depending on what the server returns will be different from one day to the next where as nix hash addresses and builds from source everything (you can use caches to speed this up) and you get the same thing every time.
Note: NixOS isn’t perfect in terms of being purely functional as many package builds use scripts in pearl,bash,etc but from my understanding these are usually source specific reproducibility issues with Building particular packages and generally speaking things works as expected.