Automatically check for channel updates

[Kommynct]

right now i've done

alias upd='doas nix-channel --update && nh os switch -f "<nixpkgs/nixos>" && nh clean all --keep 2 && notify-send --urgency=low "Update completed" >/dev/null || notify-send --urgency=low "Update Failed" >/dev/null ; pw-play --volume=0.2 /run/current-system/sw/share/sounds/freedesktop/stereo/complete.oga >/dev/null &!'

as a zsh alias, which works but i have to enter doas twice since nh calls it in its own shell, it doesn't use persistence

Honestly, why doesn't it just check for channel updates on its own? I think it would make sense, furthermore, if there's any way to make doas persist that'd be nice.

Thank you, maybe i should split this into two issues. You've made my nixos update experience nearly perfect and I appreciate it greatly!

[NotAShelf]

There is nh os switch --update, but it only supports flakes.

Given there isn't exactly a standard and grounded update mechanism for Nix2 (like how flakes are THE source of truth) I'm not exactly sure how to approach the update flag.

Previously we had discussed revising the update flag for channels and alternative pinning mechanisms such as npins, think you can find the issue open. My current "idea" is to either:

• Make --update take args on what to update, and try various mechanisms on --update-all.
• Try all tools unconditionally like we do for privilege escalation utils.

Unfortunately the pinning mechanisms are not standardized, and channel comnands require shelling out--which I'm not a huge fan of. In the end I would much prefer a PR to be submitted by someone who uses those tools extensively, so that our coverage is better and implementation is logical.

[viperML]

Would this be a good target for the Lua plugins API? Also https://github.com/nix-community/nh/issues/336

[NotAShelf]

Yes, I've meant to mention #336 in my previous reply. My thoughts are generally on handling updating as a whole. Currently I run a mix of npins and flakes for dependency locking (npins for flakeless software and flakes for, well, flakes-first software) and being able to use nh instead of relying on my custom CI workflows to keep either one of those update my different lockfiles is indeed a goal I'd like to focus on.

Though it is worth nothing that this is probably not something I'd like to handle through the plugins API. The plugins would be for pre/post command actions, and there are some architectural flaws in NH that @faukah and I are looking to tackle first. Implementing the plugins API would probably set us back a little due to added complexity, but custom update jobs are something I want to work on sooner than later. Which is to say I'll keep those separate for now.