Subject: [bug#76910] Plugin Build Conundrum

From: Gabriel Santos <[email-masked]>
Date: Sat, 29 Mar 2025 22:08:43 -0300

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

-- 
Gabriel Santos