Factor out the NixOS `meta.maintainers` module #431450

roberth · 2025-08-06T12:47:38Z

Turn the NixOS meta.maintainers module into an independent subproject, as it is useful beyond the NixOS module class.

This will allow it to be used in Modular Services (tracking) and other places.

The new /modules directory hosts this class-generic module, and it could also host specific classes such as nixosTest (VM test mix-ins) as well, though that's not part of this PR.

It also makes the option visible in the documentation and NixOS search.

Things done

Add a 👍 reaction to pull requests you find important.

`maintainers.all` does not exist, and should not exist. Neither does `alice`, but she's a metavariable.

This factors out `meta.maintainers` from NixOS `misc/meta.nix` for use in arbitrary Module System applications. It is useful beyond NixOS and not coupled to it, although it is currently coupled to Nixpkgs' `lib.maintainers`. That restriction could be lifted optionally if there's future demand.

MattSturgeon

Q: Is the intended use case to allow out-of-tree module configurations (flake-parts, home-manager, nix-darwin, treefmt-nix, nixvim, etc) to use nixpkgs' maintainer module without having to implement their own?

I'm not really familiar with modular services. Are they also a non-nixos module configuration? EDIT: it seems these modules are intended to be imported into a services submodule hosted by NixOS, nix-darwin, etc?

Q: I assume modules/ is intended to house all kinds of generic and/or non-nixos modules that end up being maintained in nixpkgs?

Without wanting to get ahead of ourselves, would it ever make sense to move the nixos modules to modules/nixos?

FYI: your "modular services" tracking link is broken. It should point to #428084 but currently points to this PR.

MattSturgeon · 2025-08-06T18:10:04Z

modules/generic/meta-maintainers.nix

+    check = email: lib.elem email (lib.attrValues lib.maintainers);
+    merge =
+      loc: defs:
+      lib.listToAttrs (lib.singleton (lib.nameValuePair (lib.last defs).file (lib.last defs).value));


Style nit: this feels unnecessarily complex just to get it formatted on a single line?

Or at least, using listToAttrs with an explicit singleton feels like a code smell.

Suggested change

lib.listToAttrs (lib.singleton (lib.nameValuePair (lib.last defs).file (lib.last defs).value));

{

${(lib.last defs).file} = (lib.last defs).value;

}

I also feel like the merge function only looking at the last definition requires some explanation and/or justification, perhaps as a comment?

Looking closer, I see this is copied as-is from the existing impl. So this isn't really feedback on your PR, but on the existing code 😅

I've done that countless times, but thanks, it works!

MattSturgeon · 2025-08-06T18:15:57Z

modules/generic/meta-maintainers.nix

+
+  maintainer = mkOptionType {
+    name = "maintainer";
+    check = email: lib.elem email (lib.attrValues lib.maintainers);


This is already hinted at in your PR description, but having the check function tightly coupled to lib.maintainers means this option-type isn't useful to projects that have their own maintainers set.

Perhaps this should be designed similarly to mkPackageOption, such that it takes a maintainers set as a function argument?

EDIT: as you already implied, this can also be tackled later in another PR.

The check function could be provided through an option then.

Good idea. Are you thinking of a meta.isMaintainer (functionTo bool) option?

Easily tested now. Thank you Matt for this suggestion! Co-Authored-By: Robert Hensing <robert@roberthensing.nl>

roberth · 2025-08-10T11:59:29Z

Q: Is the intended use case to allow out-of-tree module configurations (flake-parts, home-manager, nix-darwin, treefmt-nix, nixvim, etc) to use nixpkgs' maintainer module without having to implement their own?

They could if they wish. In flake-parts, we use a division into repositories instead, but the other projects could choose to do so if it suits them, but they are of course free to implement their own / continue to user their own.
The real reason is Modular Services.

Are they also a non-nixos module configuration?

Yes, a service module can be portable by making its systemd definitions conditional on options?systemd.

it seems these modules are intended to be imported into a services submodule hosted by NixOS, nix-darwin, etc?

Correct. I don't think nix-darwin has an implementation yet, but that is an RFC 163 goal, yes.

Q: I assume modules/ is intended to house all kinds of generic and/or non-nixos modules that end up being maintained in nixpkgs?

Correct. The directory nested inside is meant to reflect the module class, where generic/ is just a less alarming representation of the null class whose modules fit anywhere.

would it ever make sense to move the nixos modules to modules/nixos?

If we want to pull an RFC 140 by-name, then that would be a contender.
I feel like the nixos directory doesn't have quite the same degree of unnecessary chaos that pkgs did, and let's only really open that discussion after we have learned from Modular Services.

Speaking of - would could use modules/service as an alternate location for those, if tying them to a (single) package doesn't make sense.

The modules directory is based loosely on the conversation in

Replace 'configurationsXyz' and 'modulesXyz' with 'configurations.xyz' and 'modules.xyz' nix#6257

I'll put a little README in it.

Explain the purpose and usage of this new directory.

wolfgangwalther · 2025-08-10T12:13:07Z

Maybe not material for this PR, but something to consider: Is modules/ part of NixOS or not? It sounds like it is more generic than that. As such, any documentation about it, should probably not be in the NixOS manual, but in the Nixpkgs manual instead? I guess the same applies to Modular Services in general (?).

roberth · 2025-08-10T13:56:07Z

Slightly off-topic, but that's ok!

You're right. I don't want to bother the docs and website folks with this yet, but in principle I agree and we should move in that direction.
For now afaict the main implementation is in NixOS so it makes sense from a UX perspective, but that should change.
We do have some wave-particle duality going on here, whether the main value is in modularity/composition or portability. If we were to widely disagree on portability, we could skip that aspect and document everything in the NixOS manual, but I don't think that's where we're heading.

Some of it definitely belongs in NixOS though, as it is one of the configuration systems that supports those service modules.

roberth · 2025-08-17T18:51:11Z

Nixpkgs manual hint taken, because if it's not documented, it doesn't exist.
I've added a Modules section towards the bottom, after Build Helpers, but before Development.
I couldn't put them near the Module System docs, because that's in lib near the start, and I feel this should come after the bulk of package/packaging docs.

I don't want to commit scope creep, but I could add modules.generic.meta-maintainers to the flake as well?

wolfgangwalther · 2025-08-17T19:01:50Z

Q: How does this maintainer module relate to the maintainer module in lib/tests/maintainer{s,-module}.nix? Can the latter be replaced with the former?

roberth · 2025-08-18T11:08:15Z

Those files check the maintainers list in lib.maintainers, but not the meta.maintainers module.

wolfgangwalther · 2025-08-18T11:21:34Z

But shouldn't those two use the same data structure? Thus, wouldn't it make sense to re-use code to ensure they match?

roberth · 2025-08-18T11:37:27Z

Perhaps the maintainer type could be moved from test code to main code and serve a role there, but the existing checking solution works well enough for now.

roberth · 2025-08-20T13:23:06Z

The only remaining points are significant changes to the module, which I believe should not be part of this PR.

Customizing the maintainer validity check
Perhaps unifying this with the lib.maintainers test somehow

This suggests that the PR is ready, or do you wish to perform another round of review?

wolfgangwalther · 2025-08-20T13:32:18Z

This suggests that the PR is ready, or do you wish to perform another round of review?

Note: I did not actually perform any review, I just asked myself (and you) these higher level questions. I do agree they don't have to be solved in this PR at all. I'll defer to @MattSturgeon who reviewed the code for whether it's ready or not.

MattSturgeon

The diff LGTM

roberth · 2025-08-21T08:11:14Z

Thanks!

roberth · 2025-08-21T08:27:57Z

Backport failed

Label added by nixpkgs-ci account, surprisingly, but probably for some potentially valid reason.
I don't think we need a backport of this, although I wouldn't be opposed if someone did it in a month from now.

wolfgangwalther · 2025-08-21T08:31:32Z

All changes in the ci/ folder should be backported, so that we can easily backport all other changes, too, without hitting conflicts.

The "modules" folder addition in ci/eval/default.nix should not be a problem to backport, even without anything else.

roberth · 2025-08-21T09:00:57Z

I'll do that

Reason: keep ci directory in sync - #431450 (comment) This requires that we have a modules directory, in which case the easy and robust solution is to only port the addition parts of the refactor. It's about as easy as a .keep file, but more useful. This means that some duplication is created, but we avoid backporting the changes to the documentation generation, which is a somewhat complex component I'd rather not touch until these changes have been proven out on unstable.

…iners.nix (#435523)

roberth added 3 commits August 6, 2025 14:40

nixos/meta: Fix maintainers example

efaca0c

`maintainers.all` does not exist, and should not exist. Neither does `alice`, but she's a metavariable.

nixos/documentation: Allow the inclusion of a nixpkgs/modules directory

dcc0ee9

roberth force-pushed the generic-meta-maintainers branch from 5c61d61 to 0c156a7 Compare August 6, 2025 13:03

nix-owners bot requested review from philiptaron, Mic92, MattSturgeon, zowoq and wolfgangwalther August 6, 2025 13:05

roberth requested a review from nbp August 6, 2025 13:40

MattSturgeon reviewed Aug 6, 2025

View reviewed changes

modules/meta-maintainers: Refactor maintainer type merge function

79748de

Easily tested now. Thank you Matt for this suggestion! Co-Authored-By: Robert Hensing <robert@roberthensing.nl>

modules/README: init

1cafa1f

Explain the purpose and usage of this new directory.

nix-owners bot requested review from hsjobeki, GetPsyched and fricklerhandwerk August 17, 2025 18:45

doc: Add Modules, modules.generic.meta-maintainers

e9f9e2d

roberth force-pushed the generic-meta-maintainers branch from 48fff58 to e9f9e2d Compare August 17, 2025 18:46

nixpkgs-ci bot added 10.rebuild-darwin: 1-10 This PR causes between 1 and 10 packages to rebuild on Darwin. and removed 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. labels Aug 17, 2025

nixpkgs-ci bot added 10.rebuild-darwin: 1 This PR causes 1 package to rebuild on Darwin. 8.has: documentation This PR adds or changes documentation labels Aug 17, 2025

roberth mentioned this pull request Aug 19, 2025

service/portable: Add meta placeholder #435005

Merged

13 tasks

MattSturgeon approved these changes Aug 20, 2025

View reviewed changes

nixpkgs-ci bot added the 12.approvals: 1 This PR was reviewed and approved by one person. label Aug 20, 2025

roberth merged commit 4d3eb94 into NixOS:master Aug 21, 2025
30 of 32 checks passed

This comment has been minimized.

Sign in to view

This was referenced Aug 21, 2025

[release-25.05] ci,modules: Backport additions of #431450 meta-maintainers.nix #435523

Merged

portable/service: Reuse meta-maintainers.nix #435512

Merged

wolfgangwalther added a commit that referenced this pull request Aug 21, 2025

[release-25.05] ci,modules: Backport additions of #431450 meta-mainta…

88092bd

…iners.nix (#435523)

mdaniels5757 added 8.has: port to stable This PR already has a backport to the stable release. and removed backport release-25.05 Backport PR automatically labels Aug 30, 2025

Uh oh!

Factor out the NixOS meta.maintainers module #431450

Factor out the NixOS meta.maintainers module #431450

Uh oh!

Conversation

roberth commented Aug 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Things done

Uh oh!

MattSturgeon left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MattSturgeon Aug 6, 2025

Choose a reason for hiding this comment

Uh oh!

MattSturgeon Aug 6, 2025

Choose a reason for hiding this comment

Uh oh!

roberth Aug 10, 2025

Choose a reason for hiding this comment

Uh oh!

MattSturgeon Aug 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

roberth Aug 10, 2025

Choose a reason for hiding this comment

Uh oh!

MattSturgeon Aug 11, 2025

Choose a reason for hiding this comment

Uh oh!

roberth commented Aug 10, 2025

Uh oh!

wolfgangwalther commented Aug 10, 2025

Uh oh!

roberth commented Aug 10, 2025

Uh oh!

roberth commented Aug 17, 2025

Uh oh!

wolfgangwalther commented Aug 17, 2025

Uh oh!

roberth commented Aug 18, 2025

Uh oh!

wolfgangwalther commented Aug 18, 2025

Uh oh!

roberth commented Aug 18, 2025

Uh oh!

roberth commented Aug 20, 2025

Uh oh!

wolfgangwalther commented Aug 20, 2025

Uh oh!

MattSturgeon left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

roberth commented Aug 21, 2025

Uh oh!

This comment has been minimized.

roberth commented Aug 21, 2025

Uh oh!

wolfgangwalther commented Aug 21, 2025

Uh oh!

roberth commented Aug 21, 2025

Uh oh!

Uh oh!

Factor out the NixOS `meta.maintainers` module #431450

Factor out the NixOS `meta.maintainers` module #431450

roberth commented Aug 6, 2025 •

edited

Loading

MattSturgeon left a comment •

edited

Loading

MattSturgeon Aug 6, 2025 •

edited

Loading