I don’t really like flake-parts or flakelight. I think that part of this is sheer brutalism (I don’t mind writing bare Nix) but part of it is a desire to not rely on flakes which don’t carry their own weight, following Wirth’s principle for compilers.

That said, github:numtide/flake-utils does carry its own weight by managing multiple system values, especially in flakes that support more systems than upstream nixpkgs, and I’ve found myself using it in nearly everything; flake-utils makes it fairly easy to have leaf packages that are e.g. supported on both amd64 and aarch64. I know flake-parts does this too, but not in a way I enjoyed.

I just noticed that you said “my configuration.” A machine, perhaps? My NixOS configuration is split into over a dozen NixOS modules and each machine has a list of included module files. I’m not using any flake-management tools for that flake; each machine has a hardcoded system and (like sibling comment from @algernon@lemmy.ml) they’re all crammed into one big flake.nix so that the machine hostnames line up correctly when using the flake in argv:

$ sudo nixos-rebuild switch --flake git://git.example.local/one.big.flake.git

Seems facetious at first, but it facilitates automatic updates via flakes, just like with classic channels.

Can notifications be started from a systemd unit? Kind of. notify-send can be invoked from systemd, but getting the correct user notified is non-trivial and I’m not sure how it would be done on NixOS.

Can nixos-rebuild have a progress bar? Not really. It’s not a process with a predictable end time.

Can there be notifications when updates are available? There are scripts out there (like this one which I have never used) which can poll git repositories and run notify-send, but that’s not very useful. Instead, it’s worth knowing that most of the cost of auto-upgrade is running the nixos-rebuild command at all, even if there are no available upgrades!

Instead, consider setting system.autoUpgrade.dates to a fixed time when you definitely won’t use the computer, and also set system.autoUpgrade.persistent. This will run auto-upgrade on boot in the worst case.

Also, USB devices should not be disconnecting on every update. If USB disconnections happen under high load, check dmesg for possible hints; you may merely need to add an override to boot.kernelParams.