Make it possible to simulate git describe with flakes

[tobim]

Is your feature request related to a problem? Please describe. The project I work on uses git describe to generate a version string that gets baked into the output artifact at build time. in case git is not available - like when building the software with Nix - a fallback version string corresponding to the latest release is read from a file. That means that all builds except for actual releases contain inaccurate version strings. We are currently working around that by replicating the git describe invocation in an outer context, putting the result into a generated expression and evaluating that with nix build --impure. Unfortunately that approach does not work for nix run/shell or when using the project as a flake input.

This problem is currently a major factor preventing deeper adoption of Nix at my workplace.

Describe the solution you'd like A partial solution can actually be implemented in the client project with today's Nix:

• Calculate the revCount of the "to-be-tagged" commit and store that together with the fallback version string
• Read both values in flake.nix and simulate git describe with

  revCountDelta = self.revCount - lastTagRevCount;
  shortRev = "${builtins.substring 0 10 self.rev}";
  versionString = "${lastTagVersion}-${revCountDelta}-g${shortRev}";

Assuming your build scaffolds call to git describe uses a matching --abbrev for the shortRev, but that eliminates some nondeterminism so it is a good idea anyways.

This idea hinges on the availability of self.rev and self.revCount. So the solution that I'd like is to have those values defined for flake input types that often replace git, most notably type = github;. The question is how? I believe there shouldn't be any technical reason preventing us from having self.rev. But self.revCount is a bit tricky:

• Idea 1: For GitHub there is a way to get the revCount from the API: https://gist.github.com/0penBrain/7be59a48aba778c955d992aa69e524c5, Nix could do that, but even more calls to the API should probably be avoided. Maybe it could be done in a lazy fashion, only when the value is actually used during evaluation? There is a similar trick for GitLab, I haven't checked the SourceHut API yet.
• Idea 2: Lobby the Git project to embed the revCount in archive comments together with the rev. The latter is already present in tar and zip archives. This is more of a long shot obviously, and it would create wrong values when git archive runs from a shallow copy of the repo.

Describe alternatives you've considered One alternative is to compromise and give up on the revCount part. I would do that if my desired solution is ill-received or won't be implemented for the reasons mentioned above.

Related

4682 & #5385

---

I would be happy to work on the implementation for this, but I think we should come to an agreement on if and how it should be solved first.

[thufschmitt]

the solution that I'd like is to have those values defined for flake input types that often replace git, most notably type = github;

Is there a strong reason preventing you from using the git fetcher? Unless your project is fairly big that shouldn't change too much.

I'm a bit worried otherwise about adding more info to the gihub/lab/sourcehut fetchers since that will cause yet more API calls as you mention, and I fear it will complicate the logic in a non trivial way.

(fwiw, Nix itself use version strings of the form {nextReleaseVersion}pre{commitDate}_{shortRev}. Which is different from the output of git describe but serves the same purpose)

[tobim]

Is there a strong reason preventing you from using the git fetcher? Unless your project is fairly big that shouldn't change too much.

We could use it internally, but it comes with a couple of annoyances. For instance, people are used to use the github fetcher but that would (1) produce a different version compared to packages generated via other means, and (2) have a significantly lower chance of producing a cache hit. Maybe the best course of action for now is to just print an error if revCount is not available and instruct the user to use the git fetcher, but I still consider it a wart.

(fwiw, Nix itself use version strings of the form {nextReleaseVersion}pre{commitDate}_{shortRev}. Which is different from the output of git describe but serves the same purpose)

This a bit of a chicken and egg situation for projects that are only starting to use Nix. You can't expect them to change their dev version string for a new tool.

Out of curiosity: Do you have a mechanism to determine whether to omit the pre{commitDate}_{shortRev} suffix for the release version or is that always included?