Nix flakes do that. The flake.lock file automatically pinpoints not just specific versions but specific builds of each package and locks them to their hash. It will also soon be content-addressed by default which would mean that each derivation takes into account the contents of the entire dependency tree and how they relate to one another.
They technically do, but let’s say I want to have kubectl v1.10 and go v1.0 among others. Some packages do get packaged multiple times for each version. Most don’t. Then you end up hunting down build hashes for each version using tools like https://lazamar.co.uk/nix-versions/ which work I guess but the UX is not great. Talking about this with my colleagues, most won’t bother until you can declaratively list tools and versions directly
Correct me if I’m wrong: in my understanding, you could also package your own custom derivation from scratch that would do that. I agree that the UX is clunky at best but (in my perhaps incomplete understanding) you can do that today.
Nix flakes do that. The flake.lock file automatically pinpoints not just specific versions but specific builds of each package and locks them to their hash. It will also soon be content-addressed by default which would mean that each derivation takes into account the contents of the entire dependency tree and how they relate to one another.
They technically do, but let’s say I want to have
kubectl v1.10andgo v1.0among others. Some packages do get packaged multiple times for each version. Most don’t. Then you end up hunting down build hashes for each version using tools like https://lazamar.co.uk/nix-versions/ which work I guess but the UX is not great. Talking about this with my colleagues, most won’t bother until you can declaratively list tools and versions directlyCorrect me if I’m wrong: in my understanding, you could also package your own custom derivation from scratch that would do that. I agree that the UX is clunky at best but (in my perhaps incomplete understanding) you can do that today.