Subject: Re: [bug#76910] Plugin Build Conundrum

From: Andrew Wong <[email-masked]>
Date: Sat, 29 Mar 2025 20:46:59 -0400

I took a closer look at how Hyprland plugins are built, and I think more 
work will need to be done on their build system. Outside of Guix, 
plugins are built and installed by hyprland's userspace package manager, 
hyprpm, which reads a .toml file in the repository root, finds the 
plugin commit corresponding to the installed Hyprland's commit (or the 
latest commit, if there are no corresponding commits), and checks it out 
before compiling[1].

Meaning, our latest version (v3) of the patch series still has some 
issues: for one, they are all currently pulling from the incorrect 
commits, as they should be pulling from the commit specified in each 
plugin's .toml file corresponding to the currently packaged Hyprland, or 
from the latest git. For two, they will be a chore to maintain, as 
updating them correctly will involve going into each repo and checking 
their .toml file. Finally, they cannot be versioned easily, since we 
would have the (often missing) version of the plugin as well as the 
version the package is to be compiled for to contend with[2].

There are a few ways I've thought up for us to do this better:

  1. We can create a "hyprland-plugin-build-system" or 
"hyprland-plugin-phases" that emulates hyprpm by retreiving the commit 
hash of the input hyprland package (my initial thought is that we could 
use the full commit hash presented by `hyprland --systeminfo`), parsing 
the .toml file, and switching to the correct commit before building 
(maybe even parsing the build instructions given in the files?)

  2. We can package (and heavily patch to run in build-space) hyprpm to 
be used directly in the build process for plugins. Or, we could ask 
hyprpm's developers to add features to let it be used in this way (e.g. 
allowing the directories it uses to be customized) to reduce Guix' 
maintenance load, but it may be a tough sell.

  3. We can package hyprpm as a userspace tool and let it do its thing. 
It's not like it provides nonfree binaries, anyways (but it does seem to 
ask that the user pollute their profile with whatever build tools a 
plugin uses--nothing `guix shell` can't smooth over.) This is what the 
developers advise[3]. It feels very "un-guix" to let any binary build 
happen outside of a hermetically-sealed build bubble, though, let alone 
the idea of running software compiled from the "latest git".

Options 1 and 2 would make maintenance and versioning of the packages 
much easier, as you'd just have to keep them on their latest git (or 
version if they have their own version numbers) and the build system 
would take care of the rest. Option 3 would mean having no plugin 
packages to maintain in the first place.

Let me know what you all think, or if you have any ideas of your own.

- Andrew Wong

  [1] 
https://wiki.hyprland.org/Plugins/Development/Plugin-Guidelines/#commit-pins
  [2] I used to think I could version them with just the Hyprland 
version they're meant for, but then I realized that later versions of 
the plugins can change the commits corresponding to each version, so 
e.g. the Jan. 2026 version of hyprscroller for hyprland 0.51.1 could be 
different from the Mar. 2026 version of hyprscroller for hyprland 
0.51.1. I mean, I guess it could be solved with some funky extended 
version number scheme, but it wouldn't be elegant.
[3] https://github.com/hyprwm/hyprland-plugins/issues/312