Skip to content

feat(wrapperModules.niri): hot reload with new config after build #496

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
BirdeeHub merged 1 commit into from
May 3, 2026
+24 −0
Merged

feat(wrapperModules.niri): hot reload with new config after build #496

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions wrapperModules/n/niri/module.nix
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -363,6 +363,15 @@ in
as nix no longer needs to know about this path at build time.
'';
};
disableConfigHotReload = lib.mkOption {
type = lib.types.bool;
default = false;
description = ''
When `true`, the wrapper will not hot reload niri with the new config on rebuild.

Note: Niri 26.04 is required for this functionality.
'';
};
};
config.filesToPatch = [
"share/applications/*.desktop"
Expand Down Expand Up @@ -410,6 +419,21 @@ in
+ "\n"
+ config.settings.extraConfig;
};
config.buildCommand.niriReloadConfig =
lib.mkIf (!config.disableConfigHotReload && lib.versionAtLeast config.package.version "26.04")
{
after = [ "symlinkScript" ];
data = ''
chmod +w ${placeholder config.outputName}/share/systemd/user/niri.service
cat >> ${placeholder config.outputName}/share/systemd/user/niri.service<<EOF
[Unit]
X-Reload-Triggers=${config.constructFiles.generatedConfig.path}
[Service]
ExecReload=${lib.getExe config.package} msg action load-config-file --path ${config.constructFiles.generatedConfig.path}
Copy link
Copy Markdown
Owner

@BirdeeHub BirdeeHub May 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually hang on.

Question.

How does this work.

Wouldn't the service that is registered be the old one, which would have the old path?

It seems like they were doing it the same way there too but I would still like to understand what I am missing here.

Is it that since you have it specifically installed via nixos or home manager, the service gets updated, but it doesn't know that it needs to reload without this trigger, but when it reloads it reloads the new service instead of the current one?

Copy link
Copy Markdown
Contributor Author

@iynaix iynaix May 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I think happens (I'm no expert) is that the service file changes, systemd sees that the value of X-Reload-Triggers has changed, and runs ExecReload.

I did try doing it directly in buildPhase but it doesn't work in the nix build sandbox, complains about NIRI_SOCKET not being available.

Copy link
Copy Markdown
Owner

@BirdeeHub BirdeeHub May 3, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

systemd sees that the value of X-Reload-Triggers has changed, and runs E

ah ok that makes some sense actually

Given that several people have mentioned this, lgtm! Thanks for the explanation!

X-ReloadIfChanged=true
EOF
'';
};
config.meta.maintainers = [
wlib.maintainers.patwid
];
Expand Down