Subject: Re: [bug#77352] [PATCH] home: services: define hyprland home service

From: Carmine Margiotta <[email-masked]>
Date: Sat, 29 Mar 2025 18:39:15 +0100

First of all, I apologize in advance for my mistakes, but this workflow
is completely new to me!

On 3/29/25 4:37 PM, Andrew Wong wrote:
 > Very cool patch! Would it be possible to add functionality for loading
 > plugins on startup? I have a pending patch series[1] that packages
 > several Hyprland plugins, and it would be nice to be able to enter a
 > list of plugin packages to be loaded directly in the config so they
 > could be "dependencies" of the service.

This is a really interesting idea! I am not  very familiar with Hyprland
plugins - is there currently a declarative way to manage them? The only
method I know is using hyprctl.

 > Also, how does this cooperate with session managers like the default
 > GDM, which launches wayland from its .desktop entry in
 > /run/current-system/profile/share/wayland-sessions[2]? If it only
 > generates a configuration (i.e. doesn't start the Hyprland process),
 > would it be possible to define services that start and run only while
 > Hyprland runs? (this would be distinct from what "exec" lines do in that
 > the packages are then pulled into the profile by the service, letting
 > Guix "understand" the dependency)

This does not interact with session managers at all, it only generates a
configuration without starting the process itself.
For services that should run only while Hyprland is active, would this
require managing Hyprland itself via shepherd? (I am still new to Guix,
I might be mistaken here!)

 > The default settings should be the same as Hyprland's auto-generated
 > config[3], unless there's some guix-specific requirement. This is
 > because users will want to be able to easily transfer the config they
 > already use, and to be able to use the documentation and advice that
 > already exists that assumes new users have the autogenerated config.
 > Users should not have to do extra configuration to get a consistent
 > default experience.

That makes perfect sense, I will fix that asap.

 > To name a few issues, having `extra-config` defined by default would
 > require users to go out of their way to use what would otherwise be a
 > "last-resort" feature in order to get the default experience.

You raise a valid point, I will try to redesign this to implement
submaps in a more coherent way.

 > Perhaps the service could straight-up copy or parse-in the file (which
 > would make transitioning from a "traditional" config file easy, too!)
 > from the Hyprland package itself to reduce the need for Guix to maintain
 > it every time it changes. Off the top of my head, the cheapest solution
 > to the problem would be to hardcode the default config's checksum, and
 > print an alert asking for maintenance when it changes.

Your cheapest solution is good!

 > Finally, you should check over your patch with regards to Guix' coding
 > style conventions[4]. Most conspicuously, lines should be 80 characters
 > wide at maximum.

Thank you for pointing this out. I did run guix style hyprland.scm
--whole-file before submitting, but I see now that it doesn't catch line
length violations. Could you recommend any additional linting tools that
could help verify style compliance more thoroughly? I will be more
careful next time, thank you!

 > Your patch shows a lot of promise, and it's great to see someone get the
 > ball rolling on something I've only been daydreaming about for a while
 > now. If you'd like help on any specific part, LMK!

Thank you so much for your kind words!

- Carmine Margiotta