[harpratap]

It does an implicit guarantee though. You can match the image digests and it does verify that the image is exactly the same as you intended it to be. Docker also has trust signing now to make additional guarantees. Are you trying to claim that it's possible to have same image digests but the content of images is different?

[setr]

You could say it guarantees initial reproducity -- the docker image itself stays constant -- not that it guarantees complete reproducity. I would imagine nix is the solution for that goal, though I don't know nix well enough to be confident.

But an app built in a docker container is not guaranteed to have reproducible builds, because docker doesn't say anything about what happens beyond loading the initial image

[harpratap]

NixOS does the same thing. If you tell it to load python3 it will load the latest 3.7.7. You need to explicitly tell it which version of Python3 you want, just like in Dockerfile.

[progval]

That's if you're installing from a channel, because channels get updated.

If you use a local clone/submodule of nixpkgs (the git repository with the definition of all nixos packages) at a specific commit, then you will always install the exact same software, because definitions in nixpkgs all specify the exact version and the hash of all the inputs.

[abofh]

The problem is the implicit guarantee:

- Step 3: pip update && install X

- Step 4: run step-tool

- Step 5: pip update && install Y <build failure>

To be clear, I'm sure all these things can be solved by a complex enough stream of shell commands, but I'm also forced to shove in updates at every step of my build, which is an artifact of the build-system