Allow disregarding derivation name change

[Ekleog]

This is with the same context as #5: when trying to diff two NixOS revisions, if nixpkgs was updated, the derivation name of the system changes. It would be great to, in addition to listing all differences (as in #5), allow to say “disregard the derivation name change at first level”, so that the actual things changed by the nixpkgs upgrade could be checked.

[Gabriella439]

The reason this is tricky because nix-diff has no way of knowing ahead of time which differing inputs were supposed to be related other than looking at their names. For example, suppose that you had a difference in some Haskell library's dependencies that looked like this:

- attoparsec-0.13.2.2
+ megaparsec-6.5.0

You wouldn't want to descend into comparing those two dependencies, even though the names are similar, because they are unrelated.

I think the correct solution here is to fix the names to match by not making the name depend on the revision of nixpkgs. NixOS provides a system.nixos.versionSuffix option that you can set to override the revision in the name with your own fixed suffix.

In fact, I recommend setting the system.nixos.versionSuffix option in general. We had to set this option at work was because we discovered that the nixpkgs revision in the suffix was causing wasteful cache misses detected by nix-diff in this way.

See this module for more details: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/version.nix

[Ekleog]

I was thinking along the lines of a --names-are-identical=nixos-system-fubar:nixos-system-bazquux flag that would tell nix-diff to consider the two names as identical, without any more logic or guesses. This could also be used to force nix-diff to go inside a version bump of a package and figure out what changed exactly.

That said, I understand it's maybe too much complexity for what it's worth, so feel free to close this if you don't think it's a good idea. I'll go with the workaround you just suggested in this case, thanks!

[Gabriella439]

For right now, let's deal with things on a case-by-case basis. First check if using system.nixos.versionSuffix solves your problem. I don't mind adding new features if there is a concrete example where there is no alternative solution.

[Ekleog]

Hmm, I've just tried setting system.nixos.versionSuffix, but it looks like it also disrupts nixos-version. Is there any way to know with which nixpkgs revision a system was built, with your trick? (anyway, will answer the question of whether this solves the problem on next 18.03 bump)

[Gabriella439]

You don't want your system to depend on the revision of nixpkgs. The point of nix-diff is to help remove impurities like the git revision from your build so that you don't get gratuitous cache misses.

More generally, the goal of nix-diff is to promote reasoning about differences in Nix at the derivation level rather than reasoning about differences in Nix at the source code level. The specific revision of nixpkgs is a source-code-level concept that is not necessarily meaningful at the derivation level. Adding an unnecessary derivation-level dependency on the source code is (in my opinion) defeating the purpose of Nix's derivation system.

For example: if your system derivation depends on the nixpkgs revision then I know (from experience) that you will get a wasteful cache miss due to a mismatch in how the derivation is built on Hydra versus how the derivation is built from a local checkout. This is because the revision cannot be inferred from the git repository that Hydra checks out when instantiating a derivation.

[Ekleog]

Well, I kind of like (and sometimes use) the ability to go back to source code from the derivation, and was actually thinking of adding the indication of what revision my nixos-config git repo is at in the version suffix :/ I don't really care for the 96K (according to du -hs /run/current-system/) a system derivation costs me on each update (I assume that's what you're talking about with the cache misses), and was trying to use nix-diff more as a sysadmin tool (answering “what has changed in the new revision?” before switching to the new configuration) than as a nixpkgs developer (in which case knowing why cache missed becomes important).

That said, I guess we're straying pretty far off-topic (?), so will come back to report when 18.03 has moved forward, but I guess your workaround should work :)

[Ekleog]

Oh, so I was just pointed to the solution of setting system.nixos.label = config.system.nixos.release; instead of versionSuffix = "";, and it looks like it both works and allows to retrieve the nixpkgs version in /etc/os-release this way. Maybe you'd want to add that (or your solution) to the README to stop other people from opening the same issue, if they forgot to check closed issues?

Also, and perhaps more importantly, it looks like it does work, though I haven't been able to test on a nixpkgs upgrade yet, as 18.03 hasn't been bumped.

So I guess the original problem is most likely solved, and will reopen in case it fails on the next bump. Thanks a lot for your pointers!