Is this input used for anything?

Good point! We don't actually need it as an input.

Can you also update README?

virtualisation.quadlet.user, as there isn't really the concept of "user virtualisation".

I followed the convention that exists in nixpkgs:

systemd.service -> systemd.user.services

But happy to change it.

I think systend.user.services is based on that "user systemd" being something. We can have a service managed by "user systemd", or similarly a container managed by a concrete system named "user quadlet" / "user podman", rather than an abstract idea if "user virtualisation".

From the ownership perspective, the systemd module conceptually owns systemd.** options and does user vs system separation inside that scope, while quadlet-nix should probably do the same and implement the separation within its own land virtualisation.quadlet.**.

What do you think?

Yes you've convinced me. I'll make the change!

Nice. Do you want to add the same timer for rootful quadlet?

Sure can do.

Is it possible to link directly from /run/user/... without linkFarm? With that we might even be able to use $UID without relying on uid being explicitly set in nixos config.

Yea, this bit I'm not 100% happy with either. The symlinks are definitely needed so that the home manager reactivation can restart them. But while home-manager let's us write files into $HOME, it doesn't let us write symlinks directly (as far as I can find). So I used linkFarm which creates a derivation with links from generated-service-name.service to /run/user/UID/systemd/generator/generated-service-name.service

Then home-manager creates a link to the linkFarm file (which is itself a link). The end result is a chain of links:

~/.config/systemd/user/servicename.service
-> /nix/store/sn55a0wl1mxy0fnq74mqrpv0jbc97309-home-manager-files/.config/systemd/user/servicename.service
-> /nix/store/mm66x07g2jld7497s7pf8cfl3l948p4c-user-quadlet-service-symlinks/servicename.service
-> /run/user/3008/systemd/generator/servicename.service

Happy to improve it, I'm just not sure how at this point.

On second thought perhaps using home-manager's systemd.user.tmpfiles.rules would work? We'd still have to reference the user's UID somehow.

I gave systemd tmpfiles a try ("L+ ${config.xdg.configHome}/foo - - - - %t/foo"), it worked well creating the links but I can't make it delete those link when the config is removed.

I think linkFarm is fine here but getting uid from config isn't ideal as not everyone sets it. Since I don't have a good solution either (except for resorting to pkgs.runCommandLocal or activation script), I'm ok to merge the current version for now provided we make it a documented limitation (comment and README).