How to look up NixOS module maintainers in the CLI?

Help
21

Wait, meta.doc isn’t an option set. If I’m going to have to guess the mapping from an option to where I can access the metadata, I guess there’s not actually any way to do this.

22

meta.doc is an internal option, so it is hidden from the search.

I’m so confused. Your initial question was to ‘come up with a command to do the same [print the maintainers of the module] for NixOS option maintainers’. We’ve given you a command to do exactly that. No guessing required. You provide the name of an option, and this 100% correctly spits out the list of maintainers, if any. What is it that you’re actually trying to do, if you now believe that there’s no way to do this?

1 Like
23

I want to print the maintainers of a specific module, so that I can ping them easily in issues and PRs. The example I’ve given is documentation. map (x: x.github) (config.meta.maintainers.${pkgs.lib.head options.meta.doc.declarations} or [ ]) doesn’t do that, because there’s no way I could know that the options.documentation maintainers are instead fetched via options.meta.doc.declarations. And if none of the module maintainers are available inside the relevant module, then it looks like the original task is not possible in general, with the current options structure.

24

documentation is not a module! It’s a prefix for a set of options defined in multiple modules. Those modules don’t even have to import each other. Each module has a different set of maintainers. It makes no sense to ask ‘who are the maintainers of documentation’.

What you could do is enumerate all of the options that start with documentation, find their maintainers, and take the union of all of those lists. That would mean pinging some unrelated people, because the maintainers of documentation.foo may have nothing to do with the maintainers of documentation.bar, but is that what you want to do anyway?

1 Like
25

Sorry, I thought the word for a set of options was a module. That seems to be how it’s used in nixpkgs’ issue and PR templates.

I think it makes sense to ask who are the maintainers of a particular option or set of options, but it looks like that’s not set directly for most options/option sets (including documentation).

26

Yeah, ‘option set’ is not an entity that gets maintainers assigned to it. The relationship diagram is:

  • Options in a many-to-one relation to modules
  • Modules in a many-to-many relation to maintainers
  • Options in a many-to-many relation to ‘option set’?

And ‘option sets’ simply aren’t a real enough thing to have maintainers assigned to them.

What’s the use case, though? In what scenario do you want to ping everyone associated with an abstract set of options, rather than having at least one concrete option that has caused an issue for you or that you’d like to improve?

1 Like
27

The main reason would be that I don’t expect each individual option to have a maintainer, so looking for maintainers higher up the tree (ideally the first common ancestor of the relevant leaves) seems natural.

28

Maintainers belong to modules, instead of options, and a module may define 1 or more options. Modules that define 0 options are also valid. A module is a nix expression with a specific structure, most commonly represented by a single file in a context where maintainership is relevant. That structure is documented at https://nixos.org/manual/nixpkgs/unstable/#module-system.

1 Like
29

I can understand why, from first principles, you might think that’s a thing. But in NixOS, it isn’t.

It’s not simply that there’s no way to get the maintainers of an ancestor. It’s that (ignoring submodules) there is no way to assign a maintainer to an ancestor. If you wanted to make yourself a maintainer of documentation, you could not. There is no code you could submit to Nixpkgs that would do it without adding a new feature to the module system. Thus there is no point in walking up the tree.

The exception, as I said, is submodule options. Not just any prefix is a submodule; submodule is a specific type in the option system. Think systemd.services.foo.enable, in which:

  • systemd.services is an option of type attrsOf submodule,
  • systemd.services.foo is a submodule, and
  • systemd.services.foo.enable is an option in the systemd.services.foo submodule.

(systemd is not a submodule, nor is systemd.services.)

If you had gotten hold of a submodule option, in that case and in that case only, you would want to walk up the tree to get the parent option (systemd.services in this example) and determine its maintainers.

Most options are not in submodules. Nothing in the documentation tree is, in particular.

If you’re still convinced that you read somewhere that maintainership is hierarchical, you might be thinking of the ci/OWNERS file, which is a whole separate thing, and not exposed via the NixOS module system. Querying that would be a completely different task.

1 Like
30

To be clear, I don’t think I ever said I “read somewhere that maintainership is hierarchical”, I just expected it to be.