See diff between generation configurations. Or see previous generation's configuration.nix

I’ve done some nix0s-rebuild switches. Now I want to understand what I changed in my configuration.nix, but based on See changes between two generations there isn’t a way to see what the previous configuration was so I can see the difference.

Or is there a way?

I haven’t used a VCS to track changes to configuration.nix, so I’m not sure which change caused my brightness keys not to work. Maybe, I just need to reboot after the last switch as I haven’t done that yet, but anyways, it would be useful to see the full configuration for each generation (and thus be able to diff parts of it against my current).

This seems like it would be a generally useful feature for such a system as Nix/NixOS, and would greatly complement the existing feature set: being able to rollback an update is helpful, but the part that is lacking is being able to continue forward from the rollback point with understanding of what went wrong.

Keeping your configuration.nix under version control is definitely good practice, I’ve been glad I’d done it more than once.

The system.copySystemConfiguration option can help, but it has some shortcomings.

I also really like the nox-update command from the nox package – it’s able to report the differences between any two store paths. I use it to get an overview of what’s changing due to channel updates, not just configuration.nix changes.

1 Like

Yep, I’m doing it now.

I just if the default user experience with NixOS could be improved somehow. Could NixOS perhaps generate and store a diff of the /etc/nixos folder on each nixos-rebuild switch? Or maybe it can automatically track it with git and store the .git somewhere by default?

The stuff in See changes between two generations was of no help (in my case) when trying to find what a problem was between generations, because there were just so many changed packages, that it would be more productive to just try changing configuration.nix around.

(Oddly, I re-organized some code in my configuration.nix, added a few packages while basically leaving the overall end result the same as before, and now my brightness keys magically work, but I’ve no idea why, and I won’t know because now they work, and I won’t spend the huge time it takes to wade through the nix-diff output)

I had to leave NixOS for a few days to return to some other work, and once I came back, I’d already forgotten what I had modified in configuration.nix.

A feature that tracks the diff would be great!

The issue is that /etc/nixos is in not that special, you can point nixos-rebuild to a completely different configuration file by setting nixos-configuration in NIX_PATH. And even if we modified nixos-rebuild to track the file, it would not be complete because most people probably split their configuration into multiple files. And even worse, the main body of options comes from other NixOS modules than the ones user created for their configuration so the diff would be full of noise anyway.

Not saying this is not something we are interested in but it would probably require a language support; and since it is a feature that can be easily achieved by version control (a thing most people already rightly do), I doubt anyone will implement it soon.

I want a cryptographically verifiable link between a derivation and a nix expression that built it (the most common case will be NixOS’s configuration.nix, but this would be handy for any derivation).

I can greatly reduce the diff space I’d have to consider when double checking the contents of my store.

That sounds like exactly it, but a much more robust version.

At the very least, a feature that tracks the configuration file and any file it (in)directly imports within the same folder or subfolder would be helpful. I bet most of the time this is what people are interested in seeing the diff of, though that more robust version would surely be a lot better.

Perhaps some diff tool would by default show only a diff of things in the folder/subfolders where configuration.nix (or whatever the file is named) is located, and a --full option would allow one to explore everything, or something.