Include git-version and git-date

[fare]

So as to give accurate --git-version information and unstable-${date} nix version information, please include in the github.json the output of git describe --tags --always and the date of the last commit in YYYY-MM-DD format. This way, my overrides can have the exact same content as if/when they are merged into nixpkgs.

Note that git describe --tags --always can be slightly tricky to emulate without downloading an entire checkout, but I have some code in Scheme to do about the same if you know the tag you're based off of and then use some gitlab URL to get the count of commits... ugly, but works on gitlab (and something similar works on github). Still cheaper than cloning an unshallow checkout.

[3noch]

nix-thunk aims to make it inconsequential whether a thunk is packed or unpacked from the perspective of nix derivations. If the json file included meta information like this, then we'd need a way to get that same information from an unpacked (checked out) thunk such that the person asking wouldn't know the difference.

[fare]

It is 100% consequential what the name and version of the thunk are, and if nix-thunk cannot extract that information from the github.json, from git, or some other way, nix-thunk has failed me.

The programs I am using do include user-readable version information with branch / tag-relative number of commits as critical debugging / deployment tools. If I can't have that, then my users' debug logs are much less useful.

Right now, my packages use the following information:

• The output of git describe --tags --always (the revision hash in github.json is a barely passable substitute) to include in my debugging output.
• The output of git log -1 --pretty=%ad --date=short to use as the date of my nix package foo-unstable-$date, so my packages can have the proper name.

My nix recipes know how to use that information to include suitable reflection information in logs so reported bugs are reproducible (reproducibility, have you heard of this idea?). Admittedly, extracting the fallback behavior of --always via the rev field of github.json provides some semblance of reproducibility, but it won't be binary-identical to packages built from nixpkgs, thus opening the door to various cans of worms.

If this information were available, my overrides could be 100% identical to those pushed to cachix, in addition to having good names intelligible to users and informing them about how old the code and on what branch, etc.

[3noch]

Good points! I'm not suggesting your idea is bad. In fact I have wanted this too! My only point is that nix-thunk would need to provide this at the Nix level in such a way that you can't detect the difference between packed or unpacked. In the case of unpacked, it's also reasonable to assume that the source tree might be dirty in which has the git hash isn't fully reproducible. We'd need the hash of the source tree...but nix already gives us that.