mbox series

[bug#76910,v3,0/5] Add Hyprland Plugins (Update)

Message ID cover.1743265000.git.gabrielsantosdesouza@disroot.org
Headers
Series Add Hyprland Plugins (Update) |

Message

Gabriel Santos March 29, 2025, 4:16 p.m. UTC 
  This new revision add in a missing copyright statement, and a new plugin,
hypr-dynamic-cursors.

Andrew Wong (4):
  gnu: Add Hyprland plugins.
  gnu: Add hyprscroller.
  gnu: Add hy3.
  gnu: Add hypr-darkwindow.

Gabriel Santos (1):
  gnu: Add hypr-dynamic-cursors.

 gnu/packages/wm.scm | 258 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 258 insertions(+)


base-commit: 3746dcae31730ff405f49e1a32b506bfa827a3ea

Comments

Andrew Wong March 30, 2025, 12:46 a.m. UTC | #1 
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
Gabriel Santos March 30, 2025, 1:08 a.m. UTC | #2 
>hyprland's userspace package manager, hyprpm

Not /another/ one!

>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?)

This is the option I prefer. It is future-proof,
as it makes adding newer plugins a simpler process.

Though, couldn't we take over the package manager, as is
done in other build systems, such as cargo, go and node?

Even the main one, gnu-build-system, uses a command for
building, such as Make, instead of doing everything
manually.

I'm not sure I could help with this though, I don't think
I'm practical with Guix/Scheme to the point of creating a
whole new build system.

>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".

This seems to be the most likely option. And it's not
/that/ strange for Guix, as we have a well functioning
version of Nix here, which I use with home-managr
to install whatever might not be available here.

Also, from the issue you linked, it would repsect the
author's wishes.

>[3] <https://github.com/hyprwm/hyprland-plugins/issues/312>