arch_updates: hourly cache_timeout, add a note about alpm-hooks

[lasers]

I have no dog in this fight.

Alternative solution to #2215. I think this is more clean approach because it's done without trying to cache something nor confuse users with possibly some false positive / changes... For instance, if users clicked on arch_updates on the bar, would it run the updater command or just giving the users same cached information... or what if users want the updater command to be executed via clicks, py3-cmd, et cetera instead? I assume it wouldn't really update the numbers... Also, this should be much much way less polling.

I'm blindly making changes here on different distro. I would need somebody "BTW I Use Arch" to test this.

Closes #2217
Fixes #2215

[ultrabug]

@geoffliu what do you think of that please?

[lasers]

(Thought) If the py3status maintainers could add this hook for py3status and py3status-git, we could change default cache_timeout to 3600 too, then this should be better for all Arch users. Automatic (and less) refreshes.

The manual refreshes still occurs when the users restarts/reloads i3 -- which may be the reason the PR was put together, but prevents anyone from doing non-timed refreshes (say, for testing purposes).

One more thing about alpm-hook. Do we need py3status maintainers patching this hook in... or can we do that ourselves by adding the alpm-hook file? Archlinux package py3status-git may need this line... Depends = py3status-git in its hook... or we just remove the Depends.

Maybe it's possible to add various hook files ourselves for various update modules. Idk.

[lasers]

@geoffliu Pls respond.

[mlmatlock]

I must be missing the big picture.

I mean, the arch_update module cache_timeout can be configured-set a lower timeout if you don't want to wait for the default refresh rate to update the module.

You can also set up an 'on_click(x)' to run checkupdates, and that will also clear the module cache (personally have seen this behavior).

Worst case, refresh py3status.

I also think it might be better to just provide a sample hook in the module's documentation-that way the user can decide for themselves if a hook would serve them.

My 0010 cents....

[lasers]

There is (currently) no cache_timeout. I think it shouldn't be renamed (imho).

With on_click, my understanding is that it just give you same (cached) composite since the log file would have same modified timestamp. This can be a small issue with testing / debugging (nonstop logs). I am not sure about clearing module cache.

I like the idea of very small interval (10s at most) cache to prevent updater command from being executed every time somebody restarted/reloaded py3status/i3 and the idea of not having to use/rely on/read pacman_log_location config. As for refresh_interval, we often try for consistency (i.e. cache_timeout) in modules.

Improve arch_updates by asking py3status maintainers to implement hooks to refresh arch_updates after any changes instead of wasting CPU cycles all times with consistently refreshing arch_updates to read pacman_log_location timestamp... is what I'm hoping for.

[mlmatlock]

There is (currently) no cache_timeout. I think it shouldn't be renamed (imho).

Fair enough; I missed that it was changed in 24888b3.

I did have a somewhat long-winded reply in mind, but in retrospect, the module always worked fine for me (displayed number of pending updates, and didn't display when there were none hide_if_zero = true).

It wasn't a big thing if the module didn't refresh immediately after running an update, because I knew that I had just updated.

[ultrabug]

@lasers the hook you're talking about is a alpm config if I understand correctly. I don't understand what you mean by py3status maintainers "adding it". That's user optimization depending on their distro and should be kept as-is imho.

[lasers]

by py3status maintainers "adding it".

We could provide system hook just like neovim and many others.

Hooks are read from files located in the system hook directory /usr/share/libalpm/hooks, and additional custom directories specified in pacman.conf(5) (the default is /etc/pacman.d/hooks).

Source: https://archlinux.org/pacman/alpm-hooks.5.html#_description

Using an example with neovim.

$ pacman -Qo /usr/share/libalpm/hooks/nvimdoc.hook 
/usr/share/libalpm/hooks/nvimdoc.hook is owned by neovim 0.9.4-2

$ cat /usr/share/libalpm/hooks/nvimdoc.hook
[Trigger]
Operation = Install
Operation = Upgrade
Operation= Remove
Type = Path
Target = usr/share/nvim/runtime/doc/

[Action]
Description = Updating Neovim help tags...
Exec = /usr/bin/nvim -es --cmd ":helptags /usr/share/nvim/runtime/doc/" --cmd ":q"
When = PostTransaction

user optimization depending on their distro and should be kept as-is imho.

All this does is to refresh arch_updates module in more sensible way (it exists) after [install|upgrade|removal] actions rather than polling. That's us trying to optimize this particular module for this particular distro. We likely can do this for other modules on other distros too (if they exists) down the road.

And if users really don't want this, they can override hooks too.

Hooks may be overridden by placing a file with the same name in a higher priority hook directory. Hooks may be disabled by overriding them with a symlink to /dev/null.

Source: https://archlinux.org/pacman/alpm-hooks.5.html#_overriding_hooks

There are some hooks such as gtk-update-icon-cache and fc-cache -s in that system directory too.

by py3status maintainers "adding it".

With hook - https://gitlab.archlinux.org/archlinux/packaging/packages/neovim
No hook - https://gitlab.archlinux.org/archlinux/packaging/packages/py3status

[geoffliu]

@lasers @ultrabug Sorry for the late response.

This is a much cleaner solution. I wasn't so thrilled with the custom caching scheme to begin with, hence the reservation in my original PR. What would be involved in getting the arch packager to include such a hook though? Do you have experience getting that pushed through?

But I'm all for reverting my change and manually adding a hook in the meantime.

[geoffliu]

@lasers Just tested on my Arch setup, the hook file works great. Thank you for pointing this out!

[lasers]

What would be involved in getting the arch packager to include such a hook though? Do you have experience getting that pushed through?

We'd have to reach out to them both (py3status and py3status-git). Ask em nicely to add this hook. @ultrabug can do that if he is not against this... If @ultrabug is against this, then we just merge this PR reverting old change and explaining about the optional hook file... and leave this decision to users like yourself.

Same thing for other update modules in the future.

[ultrabug]

Well let's ask the Arch packager directly then, Monsieur @Antiz96 please would you consider adding a hook to the Arch package s'il te plaît ? :D

[Antiz96]

Hi everyone,

Well let's ask the Arch packager directly then, Monsieur @Antiz96 please would you consider adding a hook to the Arch package s'il te plaît ? :D

That should be doable :)

[Antiz96]

I can add the following alpm hook to the py3status [extra] package (and eventually leave a comment to the py3status-git AUR package's page so its maintainer can take the action as well, if you want me to).

[Trigger]
Operation = Install
Operation = Upgrade
Operation = Remove
Type = Package
Target = *

[Action]
Description = Refresh py3status' arch_updates module...
When = PostTransaction
Exec = /usr/bin/py3-cmd refresh arch_updates

[...] Archlinux package py3status-git may need this line... Depends = py3status-git in its hook... or we just remove the Depends.

Specifying py3status/py3status-git in the Depends variable is not needed in that case. If the file is being shipped with the package, it will be "tied-up" to it (meaning it will be installed/removed automatically with the package itself). The Depends variable is mostly used to have a dependency on additional packages (when needed).
So the Depends variable can indeed be dropped all together and the same hook file can be used for both py3status and py3status-git.

(Thought) If the py3status maintainers could add this hook for py3status and py3status-git, we could change default cache_timeout to 3600 too, then this should be better for all Arch users. Automatic (and less) refreshes.

Can this hook be added right now or should we wait for a new py3status release including the default cache_timeout change?

I remain available if needed :)

[lasers]

I can update this PR later to remove the optional note and to mention something about new hook refreshes along with new default 3600 change (if everybody agree). You can add hook right now with recently new release as it shouldn't make any difference.

The best part about this is that arch_updates would stop running updater command nonstop when users are updating a large amount of outdated packages. :)

[Antiz96]

New release v3.55 packaged in [extra] with the hook added.
See https://gitlab.archlinux.org/archlinux/packaging/packages/py3status/-/commit/6696da175ab915b174595b6e3fe103a8165cd40a

I also left a comment on py3status-git AUR package's page.

[lasers]

@ultrabug Dis ready.

[ultrabug]

Merci @Antiz96 !

[Antiz96]

Merci @Antiz96 !

De rien !