Hacker News Reader

Comment by operator-name | Hacker News Reader

This is great if you've already adopted Nix, and I'd love for nothing than more declarative package management solutions like Nix or Guix to take off.

If you're already using Docker but want to gradually adopt Nix, there is an alternative approach outlined by this talk: https://youtu.be/l17oRkhgqHE. Instead of migrating both the configuration AND container building to Nix straight away, you can keep the Dockerfile to build the nix configuration.

The biggest downside is that you don't take advantage of layers at all, but the upside is that you can gradually adapt your Dockerfiles, and reuse any Docker infrastructure or automation you already use.

View on HN

[1] also uses this approach.

[1] https://mitchellh.com/writing/nix-with-dockerfiles

So one of the pillars of the article is that docker builds aren't reproducible, but Nix is.

But... is a lot of that irreproducibiity (apologies for that word) because there's no guarantee one of the docker layers will be available?

And... does Nix have some guarantee to the end of the universe that package versions will stay in the repository?

I'd give this article a read, as it can explain it more clearly than I can: https://serokell.io/blog/what-is-nix

But to briefly answer your specific questions: Docker files are commonly not reproducible because they contain arbitary stateful commands like `apt-get update`, `curl`, etc. For a layer with these kinds of commands to be reproducible you would need a mechanism to version and verify the result.

Nix provides such a mechanism, and a community package repository with versioned dependancies between packages. These are defined in a domain specific language called Nix (text files) and kept into a git repository. This should be familiar if you've used a package manager with lock files before.

You can guarentee the package version will stay in the repository by pinning your build to an exact commit hash in the repository.

Reply on news.ycombinator.com