lib/modules: Add moduleType parameter

[roberth]

Motivation for this change

Follow-up to #143207. Allows the current configuration to be replicated and modified. Summarizing the test:

{ moduleType, ... }:
{
  options.variants = mkOption {
    type = types.lazyAttrsOf moduleType;
  };
}

  config = {
    list = [ 1 ];
    variants.foo.list = [ 2 ];
  }

assert config.variants.foo.list == [ 1 2 ]

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 21.11 Release Notes (or backporting 21.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[infinisil]

Oh my, this is really neat! Other than the small nit I think this looks good.

[infinisil]

I guess the only thing I have a slight worry about is name clashes in the module argument namespace. I don't think it's a big problem though

[roberth]

I guess the only thing I have a slight worry about is name clashes in the module argument namespace. I don't think it's a big problem though

I've thought about that too. type certainly wasn't specific enough, unlike in the evalModules output. moduleType wasn't used in Nixpkgs and I don't expect out-of-tree modules to use it either.

[nbp]

Whoa this is a highly specific use case, and strangely expressive.
However, as the test case demonstrate, there is a high risk of infinite recursions, if there is no override of the variant value to prevent such recursion.

Do you have examples where this might be used?

[roberth]

Whoa this is a highly specific use case, and strangely expressive.

💯

It is similar to extendModules, which is useful for features like NixOS specialisations and the alterations required for the NixOS docs generation to work.

However, as the test case demonstrate, there is a high risk of infinite recursions

It is productive recursion though. This is fine as long as you're not trying to compute something over all the data, which is generally not something you do in modules anyway, except in some "data" submodules (which I dislike) and in RFC42 style settings with a freeformType (which are ok).

if there is no override of the variant value to prevent such recursion.

You'd have to condition the type on a config value, which is awkward but possible. Dependent types, I guess.

Do you have examples where this might be used?

Besides the NixOS use cases, which use the same functionality via extendModules primarily, I also use it in a flake where I want to provide variations of a build and test that use a different version of an important dependency.