I cannot recommend reimplementing nixos-rebuild. If there are changes to it down the line, especially over multiple stable releases, the system could get into an unexpected state because the out of tree implementations where not considered in the migration path. I have already encountered issues where the system profile were not updated accordingly which lead to reboots reverting changes and gcroots missing.
The same for nix-collect-garbage. It may be stable now and didn’t change a lot in the past but that must not always be true for the future and messing with your nix store database could be dangerous.
We can agree on the fact, that there is a risk, though nixos-rebuild is plain broken when it comes to specialisations.
It will always activate the default. You have to manually re-activate the correct one. nh fixes this.
Also, as far as I can tell, some, if not all, remote deployment frameworks for nixos do at least partially re implement it, why not tell those the same?
From what I can tell, nh is more feature complete.
As I really hate the -d/--delete-old flag, do you also have some --delete-older-than equivalent? Perhaps by count even (keep at least 5 entries of the last 7 days)?
Is nh able to delete the GC roots, but not do an actual GC?
Can nh help me, finding auto-roots created by nix build and others? Might it even be able to help me deleting old nix-direnv “generations”?
do you also have some --delete-older-than equivalent?
No, as I don’t really use it, but I will add it to the to-do list.
Perhaps by count even (keep at least 5 entries of the last 7 days)?
This seems like a great idea. A problem I see, is that it would apply to every profile. For example: keep latest 5 entries of the nixos and HM config.
It could also have problems when dealing with HM, as it uses 2 profiles that are not synchronized (/nix/var/nix/profiles/per-user/$USER/{profile,home-manager}. Maybe home-manager-(X-5)-generation is included in profile-(Y-4)-generation, which could lead to a broken state. But it could be inspected with nix path-info, so I will need to investigate it further.
Can nh help me, finding auto-roots created by nix build and others? Might it even be able to help me deleting old nix-direnv “generations”?
My initial idea for nh clean was to clean auto GC roots, but quickly I discovered that I was “cleaning too much”, so I disabled it. A non exhaustive list of what I could find in /nix/var/nix/{gcroots,per-user}:
./result artifacts from nix build
nix-direnv gcroots
generations gcroots
Some runtime roots that I don’t know its purpose, like /home/ayats/.vscode-server/data/User/globalStorage/rust-lang.rust-analyzer/rust-analyzer or /home/ayats/.cache/nix/flake-registry.json
And I don’t know how “smart” I want to make nh clean for this task. Maybe let the user pass a pattern to match against the filenames? Or just include some default presets like cleaning result and .direnv ?
Another option would be to fork nixpkgs and adjust nixos-rebuild. I think a specialisation option is something we should add. Maybe we can query the current one and switch to that instead?
As nixos-collect-garbage is able to check by date, the age is possible to check.
Also, the generation doesn’t need to be reproducible, just the build that lead to it.
Even if you omit the date information, you can not reproduce “generation 5”. In best case you can build a “Generation x+1” that uses the same inputs as “Generation 5” back then, and therefore might even be bit-by-bit identical, but it doesn’t necessarily have to.
I agree, the store content shouldn’t know anything about actual time. But the GC-roots may of course know their age.
