I don’t agree, it is bad for reproducibility just because of the way it is implemented now, but it does not need to be bad. Registry is a bit like a DNS, you can’t always hardcode the PATH/IP (because it may change, …). I started an issue report in Regression: Nix flake ignores local registry · Issue #15441 · NixOS/nix · GitHub proposing some (possibly naive?) fixes that would fix both my issues and the issues to this original problem, so we can maybe continue the discussion there? If you think my proposition is bad, then I’d love to hear your solution to the two applications I have in mind:
- to automatically use the system nixpkgs, e.g., to reuse the original hash
- to compose local flakes elegantly (if you hardcode the path you won’t be able to deploy to a different machine)
Well, it is a good thing to have the commit frozen, this way I can upgrade when needed and revert to the old commit if needed. What I mean here is that by providing the same original hash as the system I don’t need to redownload a different nixpkgs & all dependencies for any single project I’m starting.
Well if you upgrade your system every 6 months, it still gives you enough space to make sure many projects pin the same nixpkgs. And if one is not, you just type nix flake update nixpkgs and here we go. With the new system, you need to spend time to copy/paste hashes between projects, and upgrade is also not elegant. As I said, maybe we can continue the discussion in Regression: Nix flake ignores local registry · Issue #15441 · NixOS/nix · GitHub.