feat(wrapperModules.niri): hot reload with new config after build#496
Conversation
|
Yes looks good. Thanks for this! I need to learn more about these reload if changed triggers When we get services options it might be really helpful with dealing with copying impure files for things that need writable config directories |
| [Unit] | ||
| X-Reload-Triggers=${config.constructFiles.generatedConfig.path} | ||
| [Service] | ||
| ExecReload=${lib.getExe config.package} msg action load-config-file --path ${config.constructFiles.generatedConfig.path} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
2 participants
Hot reloads niri with the new config after building, based on the conversation from: Lassulus/wrappers#135
It currently hot reloads by default, since I think it's probably the behavior most people want / expect.