This branch change mainly 2 things, the way composite types are processed, and the way internal processing of modules is done.

• Property evaluation within composite types: This change is a highly demanded feature, which tend to confuse everybody who used properties with submodules in the past. Composite types such as types.attrsOf, types.loaOf and types.listOf are now able to have properties within their bodies. The most interesting use-case involve submodule, such as jobs or file systems options:

  {config, lib, ...}:
  
  with lib;
  
  {
    options = { … };
  
    config = {
      jobs.ircSession = mkIf config.….enable {
        …
      };
    };
  }
  

  This example used to evaluate a submodule with an empty attribute set for unique submodule. With this change to the evaluation of types, which evaluate properties while merging the types, this problem no longer exists as it is equivalent to having no value to be merged. This implies that no submodule would be evaluated, and no empty job would be created.

• Argument unification between modules and submodules: This change is a long standing sanity issue which mostly prevented one person to use modules as submodules. Arguments are now processed by an internal option _module.args, which is given to each module. This implies that any set of modules which can be build in a standalone manner (such as maybe NixUP one day) can also be included as a submodule even if it relies on extra arguments, as long as these arguments are used for the computation of the definitions only.

  This open the door for a feature which I have not yet heard many people mention, but that I wanted to add for a while, which is to share library functions to build the content of option definitions. For example, the activation script logic can move to the activation script module instead of being part of nixpkgs.

  {config, lib, ...}:
  
  {
    _module.args.activationLib = {
      mkActivationWithDep = deps: str: …;
    };
  }
  

  In addition, to this change, the computation of the pkgs argument of NixOS modules moved from being computed out-side the module system to be computed within the module system. This implies that nixos/lib/eval-config.nix no longer has to execute the module system twice. The first one with a dummy pkgs argument, and the second time with the one computed from the first iteration. This approach is better as it avoid this work-around.

Sadly this last change is coming with a few non-backward compatible changes, which are either not well known, or easy to fix:

• mkOption, mkIf: These functions are part of the engine of the module system. As the pkgs argument is no longer a special argument, using pkgs.lib.mkOption will result in an infinite loop during the evaluation. Thus module should be written as { config, pkgs, lib, ... }: instead of { config, pkgs, ... }:, pkgs can still be kept for finding packages, but functions should use the lib argument. Thus pkgs.lib.mk… should be replaced by lib.mk…, and identically with pkgs.lib; should be replaced by with lib;.

• Deprecate the modulePath argument: This attribute is not well known, nor used. It was introduced before the addition of the NIX_PATH environment variable as far as I can recall. From what I can tell, the only purpose of it was to refer to nixos modules which are not included by default within your own the configuration files. This can be done as follow:

  {
     imports = [ <nixos/modules/profiles/headless.nix> ];
  }
  

• Explicit argument of modules: Due to the strictness of the deconstruction of attribute set, modules arguments are computed in a way which is similar to the callPackage function. This implies that one cannot write a module which expects any argument custom argument — other than config, lib and options — which is not explicitly named.

  { ... }@args:
  
  {
    foo.description = "${args.name} thing";
  }
  

  This example lead to the fact that name is not found on the attribute set args. On the other hand, if the attribute is made explicit, then it would be visible. This is counter intuitive, but hopefully this is not a common pattern.

  { name, ... }@args:
  
  {
    foo.description = "${args.name} thing";
  }
  

This work is based on the work made by @shlevy in pull request #2563. Reviewed carefully, rebased, and fixed.