Source: modules/misc/nixos.nix NixOS reentry can be used for both pinning the evaluation to a specific version of NixOS, and to dynamically add additional modules into the Module evaluation.

To pin a specific version of NixOS, you need a version that you can either clone localy, or that you can fetch remotely. If you already have a cloned version of NixOS in the directory /etc/nixos/nixpkgs-16-03, then you can specify the nixos.path with either the path or the relative path of your NixOS clone. For example, you can add the following to your /etc/nixos/configuration.nix file: nixos.path = ./nixpkgs-16-03/nixos; Another option is to fetch a specific version of NixOS, with either the fetchTarball builtin, or the pkgs.fetchFromGithub function and use the result as an input. nixos.path = "${builtins.fetchTarball https://github.com/NixOS/nixpkgs/archive/1f27976e03c15183191d1b4aa1a40d1f14666cd2.tar.gz}/nixos";

To add additional module, the recommended way is to use statically known modules in the list of imported arguments as described in . Unfortunately, this recommended method has limitation, such that the list of imported files cannot be selected based on the content of the configuration. Fortunately, NixOS reentry system can be used as an alternative to register new imported modules based on the content of the configuration. To do so, one should define both nixos.path and nixos.extraModules options. nixos.path = <nixos>; nixos.extraModules = if config.networking.hostName == "server" then [ ./server.nix ] else [ ./client.nix ]; Also note, that the above can be reimplemented in a different way which is not as expensive, by using mkIf at the top each configuration if both modules are present on the file system (see ) and by always inmporting both modules.

FIXME: auto-generated list of module options.