Move systemd-lib.nix and systemd-unit-options.nix into utils

[ElvishJerricco]

There are several modules that redundantly import the systemd-lib.nix and systemd-unit-options.nix files. I thought it'd be good if they all got them from the same place.

Tested with:

nix-build nixos/tests/systemd-*.nix nixos/tests/restic.nix

All test results were fetched from cache, so eval is unchanged.

[ElvishJerricco]

One minor concern I have for this PR was that I struggled for a little while with an infinite recursion issue. Turns out my issue was putting with systemdUtils.lib; after with lib;. If you put it before, then name resolution for e.g. config = mkIf will check lib.mkIf first, and not the unprepared utils expression (the module system is quirky like this).

I was thinking about removing all the uses of with on these attrsets just to discourage people from making the same mistake by looking at this code as an example of using systemdUtils. Would that be worthwhile? The networkd module could be a chore to do this to...

[ElvishJerricco]

Note: This is part of my effort to put systemd in initrd; as I'm about to make another module that uses these utils.

[Artturin]

If it's not too much trouble I'd recommend using inherit instead of with
https://nix.dev/anti-patterns/language#with-attrset-expression

[ElvishJerricco]

@Artturin Yea, there was a discussion about that (regarding this very code) on matrix earlier today. While I generally agree with the sentiment, it's worth noting that e.g. the networkd module would have a really gross let inherit. I suppose I could just prefix all the function calls with foo., but that makes for a frustratingly massive git diff.

[Artturin]

You could add a comment warning users above the with and use inherit elsewhere

[roberth]

A lot of this could be refactored into modules. We have some underappreciated possibilities in the module system could be quite helpful for keeping things together.

• Submodules can import modules.
• Options with internal = true can be used to perform computation in submodules rather than outside of them.
  For example the derivation that writes a unit can be a module. Similarly, the derivation that writes an entire systemd configuration (many units) can be a module.

This way, you won't need "utils" files as much.

[roberth]

Here's an example of this kind of refactoring #82751 (comment)

[ElvishJerricco]

@roberth I'm not exactly following what you're suggesting. How could the module system be used in this case?

[roberth]

generateUnits could go into an abstract module that reads config.units and some internal options for the other parameters.

config.systemd and config.systemd.user will have to become submodules for that to work, but I don't know if that's feasible.
Currently though, adding a submodule can be disruptive to other modules if they declare options in that part of the tree, see #146882. Might not be a problem, but I'm not sure.

It's probably best to wait for that issue to be resolved first. It seems that such a refactoring would make some of the rewiring in this PR obsolete, but this PR does not make the that change any harder, so there's no need to block this.

[roberth]

It seems to solve a problem for you.

[roberth]

It's not great that there's more wiring now, but I think we'll have to wait with systemd refactoring, as mentioned in the earlier comment.
I guess that's just the faith of "utils", to grow all sorts of weird dependencies, because everyone wants to use them for their own distinct purposes. I hope we'll remove it altogether in the future.

[ajs124]

lol, turns out this broke eval internally for all our systems on the unstable channel, because we have some cursed code that does systemdLib = import "${modulesPath}/system/boot/systemd-lib.nix" { inherit config lib pkgs; }; @dasJ

Edit: changed it to systemdLib = if utils ? systemdUtils then utils.systemdUtils.lib else import "${modulesPath}/system/boot/systemd-lib.nix" { inherit config lib pkgs; }; for added cursedness.