Describe the bug

Let's take a look at e.g. systemd.tmpfiles.settings.<name>.<name>.<name>.user.

The line itself is the first thing you get when searching for how to use systemd.tmpfiles on search.nixos.org. The problem is, how am I supposed to know what each of these <name> entries means?
Sure, you can deduce it by looking at the example from options.systemd.tmpfiles.settings, but it would be immediately obvious if it's called like this:

systemd.tmpfiles.settings.<rule-name>.<type>.<path>

(type & path are derived from tmpfiles.d(5)).

One ad-hoc way of solving that is to add some kind of namedAttrsOf function that accepts an argument for the prefix for getSubOptions, however it feels wrong to add a new "type" just for that. Also, namedAttrsOf str doesn't make much sense, it's effectively the same as attrsOf str.

But perhaps the sub-type can provide a "prefix name" to the parent? Like attrsOf (submodule { options = ...; name = ...; })? We should probably force it to be in </> for lib.showOption. Anyways, I know the knobs where to change that, but we should discuss first whether we want this and I'd need some input on how to reasonably design that.

Notify maintainers

@roberth
@infinisil

Add a 👍 reaction to issues you find important.