Is there a way to show updates in Waybar on Hyprland?

Help
1

There’s a waybar module for pacman users on Arch/Hyprland that can show which updates are pending.

I really like this feature and was wondering if anyone has done this yet on NixOS? I’m curious if anyone has made instructions like these, but for NixOS.

pacman-updates

1 Like
2

You can get similar output if you build your system and then:

nix store diff-closures /run/current-system ./result

where ./result is the symlink to new built system.

For flakes it would be something like:

nix flake update
nix build .#nixosConfigurations.$HOSTNAME.config.system.build.toplevel
nix store diff-closures /run/current-system ./result

Example output:

coreutils: +1434.5 KiB
cpupower: 6.1.92 → 6.1.93
initrd-linux: 6.1.92 → 6.1.93
openssl: +6330.8 KiB
vte: 0.76.2 → 0.76.3
zellij: -345.6 KiB
zlib: +125.2 KiB
zstd: +1146.0 KiB
linux-headers: ∅ → 6.9, +6598.5 KiB

If you only want version changes, you can grep for "→"

3 Likes
3

When I run the following command:

I get the following error:
error: flake 'git+file:///home/guttermonk/.dotfiles' does not provide attribute 'packages.x86_64-linux.nixosConfigurations.nixos.config.system.build.toplevel', 'legacyPackages.x86_64-linux.nixosConfigurations.nixos.config.system.build.toplevel' or 'nixosConfigurations.nixos.config.system.build.toplevel'

I have my flake.nix file in my ~/.dotfiles directory. Any suggestions?

4

Do you have the same name for nixosConfiguration as your hostname ?
If not, then instead of $HOSTNAME you need to use that name instead.

5

Changing the hostname variable worked. Here are the results that I got:

nix store diff-closures /run/current-system ./result
nixos-system-nixos: 24.05.20240623.e4509b3 → 24.05.20240624.fc07dc3
source: +40.7 KiB

Is there a way to have that run periodically and display the possible updates in Waybar?

6

Is there a way to have that run periodically and display the possible updates in Waybar?

Sure, write a script!

7

Looking through the Arch Waybar module for Pacman updates. Writing something like this for NixOS looks a little beyond me, but it would be a great addition to the ecosystem. Is this the kind of thing that would get done through a feature request, or is this too secondary to NixOS?

8

I think it’s misleading to have such a script for the simple reason that the idea of what a “package” is within nixworld is a lot more generalised. For example, if you change one line in a config file (let’s say even your waybar config), that can count as a net change to 3 “packages”. Unless you really like “big number go down” I wouldn’t call that useful information necessarily.

Also if this is your main machine, keeping in mind that nix is resource (ram, disk, network, cpu) hungry, you are basically kneecapping your system every time the script runs.

9

Resources are definitely something worth considering. I’ve initially set the Waybar module to update every hour, but I can scale that back if it’s slowing my system down.

Anyway, got it working. So far I like it. We’ll see how it goes.

Screenshot_2024-07-21-11-06-21_29658
Screenshot_2024-07-21-11-06-21_296581440×900 99.2 KB

1 Like
10

I’ve wanted this for a long time, is your code available somewhere ?

11

I’ve been using Linux systems for over a decade, but this is the first time I’ve been able to contribute a chunk of code of any significance back to the community. Feels good to give back to a community that’s given me so much.

If anyone has any constructive suggestions for improvement, please let me know.
https://github.com/guttermonk/waybar-nixos-updates

2 Likes
12

Overall the script looks good, I think nvd is good at cutting out a lot of noise in the changes.

My specific suggestions:

  • I’d use $(hostname) instead of $HOSTNAME, keeps things a little more flexible.
  • I don’t know if you’d consider this an “improvement” as it depends entirely on your personal workflow; if I was implementing this I’d be conscious to avoid updating the original flake when getting the updates, but update a copy instead, or use something like --override-input - that way the original lockfile stays untouched and I can update that at my leisure. It also prevents the scenario when I want to make a change right away, but there’s some other incompatible change on the newer nixpkgs that I don’t have time to deal with right now.
  • I’d also usually consider error handling (i.e. save the return code from the update command and if it’s nonzero, display a heads-up about that).
1 Like
13

Thanks for the suggestions. Out of curiosity, how does $(hostname) keep it more flexible? For the second point, not really sure how to pull this off. I’m not seeing any examples of --override-input that make any sense. How would this argument be used here? For the error handling, are you saying it should possibly show a notification with the potential updates? Right now, any non-zero outputs indicate the number of updates pending, which is displayed in Waybar.