This module is actually a bit of a pet peeve of mine and a big reason I soured on Home Manager in general…
You inevitably end up writing chimera configurations like this:
# home.nix
programs.sway = {
enable = true;
# not supported by module - need to use escape hatch
# good luck getting your editor to syntax highlight this snippet btw
extraConfig = /* swayconfig */ ''
bindgesture swipe:right workspace prev
bindgesture swipe:left workspace next
'';
};
programs.waybar = {
enable = true:
# can't do that in Nix
style = /* css */ ''
window#waybar {
background: #16191C;
color: #AAB2BF;
}
'';
};
# configuration.nix
# need to enable Sway a second time so the display manager can see it
# this may also install a second Sway if you fuck up your HM setup
programs.sway.enable = true;
and in exchange for this you get:
30s+ iteration times for basic changes like keybinds
No ability to copy paste config snippets from READMEs/Wikis (unless you use home.file/extraConfig escape hatches)
No ability to edit configuration in scripts (breaks a lot of theming functionality in “shells” like DMS, Noctalia, etc.)
More ways to write configs that look right but don’t quite work or just do dumb things (extra Nixpkgs imports, duplicated packages, WMs that aren’t visible to the DM, etc.)
Alternatively you could just use a dotfile manager like rcm or stow or chezmoi like everyone not on NixOS+HM and not have to deal with any of this.
Yeah, I can understand the frustration. IMHO the Home-Manager way of doing things has some merits:
You can (generally) manage the installation of packages together with their configuration.
You can override individual configuration values for different machines (which I guess, you can also do via templating in chezmoi).
Some programs don’t have a particularly readable configuration file or spread this configuration out over multiple files, or save all kinds of additional garbage into their configuration file which you don’t want to persist. Home-Manager can work around all these issues, and in such a case is likely also better documented than the original configuration file.
That last point is one that’s particularly relevant for me, because KDE Plasma’s configuration files are largely terrible. Home-Manager, together with Plasma-Manager, is the only sane way I know of, to automate the panel configuration in KDE.
But yeah, if you don’t use software with terrible configuration files, then I can certainly understand preferring dumb templating. I have also decided against using the Home-Manager-specific modules in places, or might only translate into the Home-Manager-specific module when I actually want to vary configuration values between two machines.
Just to give a quick impression of how terrible the KDE panel configuration is, this is a snippet out of the fittingly-called plasma-org.kde.plasma.desktop-appletsrc file:
Ah sorry, that doesn’t actually show any of the panel configuration, because KDE mixes configuration for the panel and desktop widgets and the Activities feature (like workspaces, but with separate wallpapers and widgets for each Activity) all into the same file.
So, here’s a snippet that actually shows the panel configuration, from just a few lines below the first snippet:
What those numbers in e.g. [Containments][1807][Applets][1812] are? Ah, they just count those from 0 to infinity, whenever you add a widget through the UI.
And in case you were wondering since when INI allows for nesting section keys via [multiple][brackets]: It doesn’t. That’s a custom extension of the INI format, specifically in use by KDE.
Like, man, I love KDE for its features, but this is the stuff of nightmares.
I remember home-manager integrated with flakes being a nightmare for my potato laptop because I defined even the bash alias and such stuffs in it and even if I had to change/add a simple alias I had to rebuild the whole system lol, I could have just used home-manager standalone to be honest(I forgot to do this) but I just switched to using the old way of managing dotfiles with stow.
So right now I have it defined in the .config/sway/config file like this:
Does Home Manager not just have a dot file manager built in? On Guix, I just have my Waybar config. get moved to the appropriate location that Waybar will expect it.
Some services will even allow you to specify files to get injected into the config.; like the Bash service so I can write some definitions out in a .sh file and the service inserts that contents after the boilerplate it provides into my .bashrc.
This module is actually a bit of a pet peeve of mine and a big reason I soured on Home Manager in general…
You inevitably end up writing chimera configurations like this:
and in exchange for this you get:
home.file/extraConfigescape hatches)Alternatively you could just use a dotfile manager like rcm or stow or chezmoi like everyone not on NixOS+HM and not have to deal with any of this.
Yeah, I can understand the frustration. IMHO the Home-Manager way of doing things has some merits:
That last point is one that’s particularly relevant for me, because KDE Plasma’s configuration files are largely terrible. Home-Manager, together with Plasma-Manager, is the only sane way I know of, to automate the panel configuration in KDE.
But yeah, if you don’t use software with terrible configuration files, then I can certainly understand preferring dumb templating. I have also decided against using the Home-Manager-specific modules in places, or might only translate into the Home-Manager-specific module when I actually want to vary configuration values between two machines.
Just to give a quick impression of how terrible the KDE panel configuration is, this is a snippet out of the fittingly-called
plasma-org.kde.plasma.desktop-appletsrcfile:[ActionPlugins][0] MiddleButton;NoModifier=org.kde.paste RightButton;NoModifier=org.kde.contextmenu [ActionPlugins][1] RightButton;NoModifier=org.kde.contextmenu [Containments][1122] activityId=f588743a-9bab-4f56-8f90-3616085ab6e0 formfactor=0 immutability=1 lastScreen=1 location=0 plugin=org.kde.plasma.folder wallpaperplugin=org.kde.color [Containments][1122][Wallpaper][org.kde.color][General] Color=#79740eAh sorry, that doesn’t actually show any of the panel configuration, because KDE mixes configuration for the panel and desktop widgets and the Activities feature (like workspaces, but with separate wallpapers and widgets for each Activity) all into the same file.
So, here’s a snippet that actually shows the panel configuration, from just a few lines below the first snippet:
[Containments][1807] activityId= formfactor=3 immutability=1 lastScreen[$i]=0 location=5 plugin=org.kde.panel wallpaperplugin=org.kde.image [Containments][1807][Applets][1808] immutability=1 plugin=org.kde.plasma.showActivityManager [Containments][1807][Applets][1810] immutability=1 plugin=org.kde.plasma.pager [Containments][1807][Applets][1810][Configuration][General] showOnlyCurrentScreen=true showWindowIcons=true wrapPage=true [Containments][1807][Applets][1811] immutability=1 plugin=org.kde.plasma.panelspacer [Containments][1807][Applets][1812] activityId= formfactor=0 immutability=1 lastScreen=-1 location=0 plugin=org.kde.plasma.systemtray popupHeight=432 popupWidth=432 wallpaperplugin=org.kde.imageWhat those numbers in e.g.
[Containments][1807][Applets][1812]are? Ah, they just count those from 0 to infinity, whenever you add a widget through the UI.And in case you were wondering since when INI allows for nesting section keys via
[multiple][brackets]: It doesn’t. That’s a custom extension of the INI format, specifically in use by KDE.Like, man, I love KDE for its features, but this is the stuff of nightmares.
Well, is it like that using home manager?
I remember home-manager integrated with flakes being a nightmare for my potato laptop because I defined even the bash alias and such stuffs in it and even if I had to change/add a simple alias I had to rebuild the whole system lol, I could have just used home-manager standalone to be honest(I forgot to do this) but I just switched to using the old way of managing dotfiles with
stow.So right now I have it defined in the
.config/sway/configfile like this:input * { xkb_layout "us" xkb_options "caps:ctrl_shifted_capslock" }Maybe I will come back to using standalone home-manager one day.
Does Home Manager not just have a dot file manager built in? On Guix, I just have my Waybar config. get moved to the appropriate location that Waybar will expect it.
Some services will even allow you to specify files to get injected into the config.; like the Bash service so I can write some definitions out in a .sh file and the service inserts that contents after the boilerplate it provides into my
.bashrc.It does, that’s the
home.fileescape hatch I mentioned. But then you end up paying 10-30 seconds eval for a “config” that looks like this:I suppose there are fringe use cases where Nix attrset merging behaviour is useful, but in the average case I just don’t see much value here.