Home Explore Blog Models CI



nixpkgs

2nd chunk of `nixos/doc/manual/configuration/modularity.section.md`
ec7041c67d50edf5f18f09082a9e4ad2f57917566d1740010000000100000bb7
[](#opt-environment.systemPackages). When multiple modules define an
option, NixOS will try to *merge* the definitions. In the case of
[](#opt-environment.systemPackages) the lists of packages will be
concatenated. The value in `configuration.nix` is
merged last, so for list-type options, it will appear at the end of the
merged list. If you want it to appear first, you can use `mkBefore`:

```nix
{ boot.kernelModules = mkBefore [ "kvm-intel" ]; }
```

This causes the `kvm-intel` kernel module to be loaded before any other
kernel modules.

For other types of options, a merge may not be possible. For instance,
if two modules define [](#opt-services.httpd.adminAddr),
`nixos-rebuild` will give an error:

```plain
The unique option `services.httpd.adminAddr' is defined multiple times, in `/etc/nixos/httpd.nix' and `/etc/nixos/configuration.nix'.
```

When that happens, it's possible to force one definition take precedence
over the others:

```nix
{ services.httpd.adminAddr = pkgs.lib.mkForce "bob@example.org"; }
```

When using multiple modules, you may need to access configuration values
defined in other modules. This is what the `config` function argument is
for: it contains the complete, merged system configuration. That is,
`config` is the result of combining the configurations returned by every
module. (If you're wondering how it's possible that the (indirect) *result*
of a function is passed as an *input* to that same function: that's
because Nix is a "lazy" language --- it only computes values when
they are needed. This works as long as no individual configuration
value depends on itself.)

For example, here is a module that adds some packages to
[](#opt-environment.systemPackages) only if
[](#opt-services.xserver.enable) is set to `true` somewhere else:

```nix
{ config, pkgs, ... }:

{
  environment.systemPackages =
    if config.services.xserver.enable then
      [
        pkgs.firefox
        pkgs.thunderbird
      ]
    else
      [ ];
}
```

With multiple modules, it may not be obvious what the final value of a
configuration option is. The command `nixos-option` allows you to find
out:

```ShellSession
$ nixos-option services.xserver.enable
true

$ nixos-option boot.kernelModules
[ "tun" "ipv6" "loop" ... ]
```

Interactive exploration of the configuration is possible using `nix
  repl`, a read-eval-print loop for Nix expressions. A typical use:

```ShellSession
$ nix repl '<nixpkgs/nixos>'

nix-repl> config.networking.hostName
"mandark"

nix-repl> map (x: x.hostName) config.services.httpd.virtualHosts
[ "example.org" "example.gov" ]
```

While abstracting your configuration, you may find it useful to generate
modules using code, instead of writing files. The example below would
have the same effect as importing a file which sets those options.

```nix
{ config, pkgs, ... }:

let
  netConfig = hostName: {
    networking.hostName = hostName;
    networking.useDHCP = false;
  };

in
{
  imports = [ (netConfig "nixos.localdomain") ];
}
```

Title: NixOS Module Option Management and Advanced Techniques
Summary
This chunk details how NixOS modules handle configuration option merging, access to the complete system configuration, and tools for inspection. It explains that list-type options are concatenated (with `mkBefore` for order control), while unique options trigger errors unless `pkgs.lib.mkForce` is used for explicit overriding. Modules can access the fully merged configuration via the `config` argument, allowing for conditional settings. The `nixos-option` command and `nix repl` are introduced as tools for exploring the final configuration, and it's also shown how modules can be programmatically generated within the configuration.