Is there a way to access version control information from within a build?

Help
1

Hello all,

I have a situation where I need to know some version control information (specifically, the mercurial bookmark) at build-time. The bookmark itself can be accessed either from a file within the ./.hg folder of a repo, or using the hg bookmark command. However, nix strips out this information from both the /build and $out directories, meaning that neither of these are available at build-time.

The best solution I can think of here is have a script to print the bookmark to a file elsewhere in the repo, and to somehow hook this script into either nix build or hg up (the command which changes the mercurial rev). Both of these feel slightly clumsy though and I’m sure there’s edge cases where they’d not work. Is anyone able to think of something more robust?

Thanks!

2

Don’t know anything about mercurial but for git there is leaveDotGit which is generally the least reproducible way, it could be derived from version, be replaced with a static value or just be committed completely.

3

Thanks, it seems that leaveDotGit does cause the .hg directory to be left as well, so this solves my problem. When you say it’s the “least reproducible way”, could I ask what you mean by that? The only downside I can readily see is that it might cause the same source code to (unhelpfully) lead to two different nix packages, if there are differences in the .hg folder files.

4

The .git (and probably .hg, too) directory are not fully reproducible under all circumstances forever. Think about changes in the tools themselves or race conditions when downloading. I would need to lie about the specifics but if I remember things correct then a rename in a remote could trigger something like that but take that with a grain of salt. Usually submodules are also a good source for a hash change over time or .gitattributes files.

5

OK. Maybe I am misunderstanding what you mean by reproducible here, but if I am just reading a string from one of these files, I don’t think that this matters?

6

The fetch functions in nixpkgs produce fixed-output derivations that requires a hash, it being not reproducible can invalidate the hash and break the build, so It’s probably a good idea to remove the unreproducible stuff in postFetch. Here is an example I found in nixpkgs:

7

Aah, OK. Thanks, that’s clear.