hjem systemd should link individual service files instead of the ~/.config/systemd/user folder

[fred21O4]

I use clobberByDefault = true, and I also create systemd user services outside of nix in ~/.config/systemd/user
When I started using hjem I noticed my user services had disappeared.
It seems currently that hjem links the entire ~/.config/systemd/user folder instead of individual files and due to hjem.user.<name>.systemd.enable being true by default, even without any services configured, hjem will replace ~/.config/systemd/user with an empty folder.
This will most likely not occur with clobberByDefault = false, however I believe it would be preferable to be able to use hjem systemd alongside imperative systemd user units.

hjem should probably be changed to link individual service files instead of the entire folder, especially if hjem.user.<name>.systemd.enable is on by default as it was surprising to me that it even touched my services without any configured in hjem.

I will be happy to work on a pr that changes this behaviour if it is a desired change.

[eclairevoyant]

NixOS doesn't support this at the system level, so we weren't planning to do so at the user level either.

Can you explain why you would want imperative systemd units? The paths would inevitably be wrong (and even break on GC), among other issues like programs being able to throw broken units into the user dir. Hjem is the user-level declarative counterpart to what NixOS does at the system level.

[fred21O4]

I admit my use case is a bit hacky, but the service runs a script that uses nix-shell as an interpreter to add dependencies.
It doesn't currently but I'm sure I could tweak it to use gcroots to avoid it needing to re-fetch deps after a gc.
Plus while I don't personally use any, ~/.config/systemd/user isn't exclusively for services and some users may need imperative systemd.path units or other such units that don't depend on any nix store paths.

Also nixos has systemd.user options that fit this use case, combining this with ConditionUser can replicate user specific units without touching ~/.config/systemd/user so maybe making hjem.systemd an alias to this approach is more desirable then touching ~/.config/systemd

In any case I don't feel like hjem should be forcing users to use exclusively hjem systemd over being able to use both imperative and declarative approaches at the same time.

If you disagree, I still think making the hjem systemd module not overwrite ~/.config/systemd/user when no services are configured makes sense.

[eclairevoyant]

I still think making the hjem systemd module not overwrite ~/.config/systemd/user when no services are configured makes sense.

This I can agree with. But we have the .enable gating this overall 🤔
I guess we can reconsider the default in that case.

[fred21O4]

Yes currently I have set .enable to false which does work.
changing it to: mkIf (cfg.enable && cfg != {}) is how I would do it, keeps .enable defaulting to true, but if nothing is configured, doesn't touch ~/.config/systemd/user.

[fred21O4]

happy to close the PR as this is fine for me, If I need systemd services in nix, I can use nixos systemd.user options over the hjem option, e.g:

systemd.user.services.<name> = {
  unitConfig.ConditionUser = <user>;
  ...
};

[eclairevoyant]

As mentioned on the PR - recursive linking would be useful in general, so we'll implement that and have our systemd module use it; that should prevent this issue.