3 ms·
So this is why I create Nix files for all of my projects and do all builds from within a nix-shell. You then get to decide to what extent you want to freeze yo
by ris 9y ago
So this is why I create Nix files for all of my projects and do all builds from within a nix-shell.
You then get to decide to what extent you want to freeze your exact dependencies or leave them abstract to some degree.
- Phlogistique 9y agoAnd do you freeze the nixpkgs version as well?
- ris 9y agoAgain, depends. It's a tradeoff. As much as you want reproducibility, you never really want to be wed to security bugs. I tend not to but generally consider myself on the fence about that one.
- chriswarbo 9y agoI hard-code ("freeze") known-good versions of dependencies (including nixpkgs) in my derivations; but I also check to see if an override has been given in NIX_PATH (using `builtins.tryEval <foo>`). This way, I can override things if needed; and in particular I have continuous integration (Hydra) building both a "stable" (all fixed versions) and "unstable" (all latest versions). This way I always have a known-good build I can use, but I can still spot impending breakages and bit-rot in CI. In the case of nixpkgs I don't actually track the very latest commit, since it updates so often. Instead I just `git pull` into a fork every now and again.