Record the revision of a reference upon locking. Optionally also a hash over the contents.

[FRidh]

The lock file currently records only references. References (such as tags) are mutable, and thus the lock file does not achieve reproducibility. Upon locking the reference should be recorded (as it is now) but also the revision the reference was at at that time. Please see also the discussion at NixOS/nix#3216

Also, have a look at the following example lock file of what is recorded https://github.com/NixOS/nix/blob/master/flake.lock. narHash is essentially the hash over the contents (minus any version control files) and is used by the Nix package manager so it does not need to perform a version control checkout anymore. That I think goes a bit too far for here.

@ehmry, as maintainer of https://github.com/nix-community/flake-nimble, do you have any more input regarding the lock format?

[disruptek]

The problem is that Nimble does not give us much to work with -- normal Nimble installations, which Nimph nominally supports, often don't even have tags or commits for us to inspect.

So, sure, we can do lockfiles using commit hashes trivially, but then Nimble will be a second-class citizen that taints lockfiles, rendering them unreproducible. If you want to submit a PR to that effect, I'm happy to merge it. Maybe a --force option will override the discovery of a Nimble package included in the lockfile?

FWIW, I really don't care what other languages or environments produce, and to me, the idea that a tag's mutability is a liability is arguably ridiculous. If you cannot trust your source to tag itself in a sane manner, maybe you should be pointing at a fork instead. It's quite trivial to do so using Nimph.

[FRidh]

FWIW, I really don't care what other languages or environments produce, and to me, the idea that a tag's mutability is a liability is arguably ridiculous. If you cannot trust your source to tag itself in a sane manner, maybe you should be pointing at a fork instead.

All refs are mutable. That includes not only tags but also branches.

[disruptek]

The point remains; commit hashes are immutable and are trivial for us to include in lockfiles, but again, they don’t solve the actual problem.

If you’re not interested in solving actual software development problems that real software developers have with real Nim software, then by all means, close the issue.

Nimph solves real problems.

[disruptek]

Actually, I added this to the Nimble dependency milestone because I'm just going to rip Nimble support out of Nimph. It solves a number of problems and allows us to proceed with the assumption that no Nimble packages exist. This means that the lockfiles can hold hashes, as I've alluded to in every comment I've made on this issue, despite no apparent acknowledgement.

Are hashes somehow unworkable for Nix?