Flakes don't discover git references?

Development
1

(according to https://github.com/tweag/rfcs/blob/ca2845b81814c345945de4be0b36cd5fb4eb080b/rfcs/0049-flakes.md)

Such as v1.5.6 or development or master.

Use case:

{
[...]
                    buildFlagsArray = ''
                      -ldflags=
                        -w -s
                        -X main.version=${self.?????????????}
                        -X main.commit=${self.rev}
                        -X main.date=${self.lastModifiedDate}
                        -X main.builtBy=nix-flakes
                    '';
[...]
}

What do?

2

Or only not documented?

EDIT (maybe the answer is no):

$ nix shell
warning: Git tree '/home/blaggacao/ghq/github.com/zegl/kube-score' is dirty
error: --- EvalError --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- nix
in file: /nix/store/a5icqippdiizsqh3c0639niiarrcin52-source/flake.nix (19:44)

attribute 'ref' missing
(use '--show-trace' to show detailed location information)

My version:

$ nix-env -iA nixpkgs.nixFlakes
replacing old 'nix-2.4pre20200622_334e26b'
installing 'nix-2.4pre20200622_334e26b'
building '/nix/store/8lwy879993pddrdyshxby51phzadpvi7-user-environment.drv'...
3

Indeed attributes like the ref or repository URL are not passed to the outputs function. This is intentional - for ensuring hermetic evaluation, and for evaluation caching, it would be bad if the evaluation result could be different depending on what branch/tag name you used to fetch the input. (E.g. the same commit on the release-20.03 and nixos-20.03 branches of the nixpkgs repository should produce the same evaluation result.)

4

Ah! Thanks!

But actually, if a program wants to reason about it’s version (aka --version), then version information (or mostly nowadays a git tag) is part of the input and should also be part of the hermetic evaluation.

In the actual implementation it’s in the form of a text field still part of the input.

But this input needs to be manually updated.
This is bad for the “most up to date” packaging system out there.

And I thought since people will do github:foo/bar/v1.2.3 they already express their intent about one particular version.

The only thing I could see really breaking the deal is that references can be updated. So essentially they are weak guarantees. Hm…

On the other hand, self.rev (as a strong guarantee) must be present for self.ref to be even thinkable of.

Re caching: in the end, people will probably request github:foo/bar/v1.2.3 most of the time, anyways. Not sure about implications for CI, though.

5

Idea: what about inferring all current references from a specific commit and pass them as sorted string?

Most of the time it’s just one anyway. in case those are more than one, it’s ugly, but at least it doesn’t invalidate caches.

Clearly it couldn’t be called self.ref, then. Rather self.refStr.

EDIT: Learned that this would be only possible for git type since github doesn’t actually fetch history.

6

The problem is dropping semver for commit hashes in favor of packaging maintainability, for example in logs makes quick reasoning about the graph direction very improbable for the human log consumer.

7

Opened an issue to track this in my opinion important aspect, while distinguishing develompent/ci use cases from distribution use cases: flake to "input" invoking git references in addition to revisions · Issue #3838 · NixOS/nix · GitHub

8

For now I solved the maintainability burden like so: chore: package as nix flake by blaggacao · Pull Request #274 · zegl/kube-score · GitHub

But this is essentially equivalent to renouncing to the semantic communicative value of semver. :cry:

1 Like