nix flake check: Allow modules attribute

[roberth]

Motivation

Do not warn about another known community attribute, which solves the problem for potentially all "modules" attributes.

Contrext

• Implements part of Replace 'configurationsXyz' and 'modulesXyz' with 'configurations.xyz' and 'modules.xyz' #6257

This is intended as a module system "library" in the format

<flake>.modules.<class>.<name>

where class is e.g. "nixos" or "homeManager", and the name is of the author's choice.

Modules that can be loaded in any module system application should use the name "generic".

• Implemented in the module system in module system: Improve error messages around faulty imports nixpkgs#197547

• Class parameter for checking: https://nixos.org/manual/nixpkgs/stable/index.html#module-system-lib-evalModules-param-class

Priorities and Process

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[edolstra]

Not really in favor of this since such a generic attribute would be uncheckable via flake schemas (#8892). So then we may as well provide a flake output attribute named "generic" or "freeform" or something like that.

I'm also not convinced that a two-level hierarchy modules.<class>.<name> is any better than <class>Modules.<name>.

Are there any real-world use cases for modules that can be loaded into any module system?

[Mic92]

Something to consider is that the duplication would make it harder for nix tooling. Now you would need to check both .nixosModules and .modules.nixos, so any change needs to have a very good reason to justify the cost onto the ecosystem. Do we have stats how widely this is used?

[roberth]

@edolstra what is even checkable about modules? Their syntax can be attrsets or functions, and it's only since recently that we can potentially check some modules, if they set _class, which kinda needs to be done by frameworks, which is rare for now.
Option definitions are not checkable without having a full configuration, and knowing which option(s) must be valid for a given module system application. The latter could be taught by hardcoding or "schemas", but the prior makes it a non-starter.

I'm also not convinced that a two-level hierarchy modules.<class>.<name> is any better than <class>Modules.<name>.

It's a single schema for all module system applications. This allows for more generalized tooling, such as aforementioned frameworks, a library that makes imports more convenient, that kind of thing. All while saving unnecessary boilerplate.
By removing that boilerplate, it is also feasible to have more custom classes, such as configurations for individual services (ie at the submodule level when applied in NixOS, etc). These are new usages of the module system; for instance a design for RFC 163 Portable Service Layer would make these patterns more prevalent, and therefore make the reduction of flake schema boilerplate actually useful.

Are there any real-world use cases for modules that can be loaded into any module system?

This is only relevant for modules.generic.<name>, but yes, they do exist. Examples:

• assertions.nix
• documentation generation (assuming a pkgs module argument perhaps, but that's available in most module system applications)
• misc/nixpkgs.nix (or a replacement without the legacy options)
• meta.nix

There's also interest in having generic modules for external reuse

• Expose some additional nixosModules nixpkgs#261660
• nixos: reusable assertions nixpkgs#207187 (comment)

Now you would need to check both .nixosModules and .modules.nixos, so any change needs to have a very good reason to justify the cost onto the ecosystem.

The very good reason that justifies it is that it allows modules for all module system applications to be checked with the same code and no per-application boilerplate. We could deprecate all .<class>Modules, reducing the complexity of the ecosystem rather than increasing it.

Do we have stats how widely this is used?

No, but I don't think it's all that relevant.
How should conventions be changed? This exists in no-man's land between Nix and many other organizational boundaries.
A worse but good enough solution already exists, and nobody has signaled that modules.* might actually become a replacement. So why would the ecosystem anticipate a change that might not come?

Nonetheless, #6257 is a 3rd percentile 👍 issue.