summary refs log blame commit diff
path: root/nixos/doc/manual/configuration/modularity.xml
blob: 59a4e3b33ba1992ed2b1dca0ca31213b40ff10f5 (plain) (tree)


































































































































                                                                                                                                     
                               










                                                                
<section xmlns="http://docbook.org/ns/docbook"
         xmlns:xlink="http://www.w3.org/1999/xlink"
         xmlns:xi="http://www.w3.org/2001/XInclude"
         version="5.0"
         xml:id="sec-modularity">

<title>Modularity</title>

<para>The NixOS configuration mechanism is modular.  If your
<filename>configuration.nix</filename> becomes too big, you can split
it into multiple files.  Likewise, if you have multiple NixOS
configurations (e.g. for different computers) with some commonality,
you can move the common configuration into a shared file.</para>

<para>Modules have exactly the same syntax as
<filename>configuration.nix</filename>.  In fact,
<filename>configuration.nix</filename> is itself a module.  You can
use other modules by including them from
<filename>configuration.nix</filename>, e.g.:

<programlisting>
{ config, pkgs, ... }:

{ imports = [ ./vpn.nix ./kde.nix ];
  services.httpd.enable = true;
  environment.systemPackages = [ pkgs.emacs ];
  <replaceable>...</replaceable>
}
</programlisting>

Here, we include two modules from the same directory,
<filename>vpn.nix</filename> and <filename>kde.nix</filename>.  The
latter might look like this:

<programlisting>
{ config, pkgs, ... }:

{ services.xserver.enable = true;
  services.xserver.displayManager.kdm.enable = true;
  services.xserver.desktopManager.kde4.enable = true;
  environment.systemPackages = [ pkgs.kde4.kscreensaver ];
}
</programlisting>

Note that both <filename>configuration.nix</filename> and
<filename>kde.nix</filename> define the option
<option>environment.systemPackages</option>.  When multiple modules
define an option, NixOS will try to <emphasis>merge</emphasis> the
definitions.  In the case of
<option>environment.systemPackages</option>, that’s easy: the lists of
packages can simply be concatenated.  The value in
<filename>configuration.nix</filename> 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 <varname>mkBefore</varname>:

<programlisting>
boot.kernelModules = mkBefore [ "kvm-intel" ];
</programlisting>

This causes the <literal>kvm-intel</literal> kernel module to be
loaded before any other kernel modules.</para>

<para>For other types of options, a merge may not be possible. For
instance, if two modules define
<option>services.httpd.adminAddr</option>,
<command>nixos-rebuild</command> will give an error:

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

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

<programlisting>
services.httpd.adminAddr = pkgs.lib.mkForce "bob@example.org";
</programlisting>

</para>

<para>When using multiple modules, you may need to access
configuration values defined in other modules.  This is what the
<varname>config</varname> function argument is for: it contains the
complete, merged system configuration.  That is,
<varname>config</varname> is the result of combining the
configurations returned by every module<footnote><para>If you’re
wondering how it’s possible that the (indirect)
<emphasis>result</emphasis> of a function is passed as an
<emphasis>input</emphasis> 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.</para></footnote>.  For example, here is a module that adds
some packages to <option>environment.systemPackages</option> only if
<option>services.xserver.enable</option> is set to
<literal>true</literal> somewhere else:

<programlisting>
{ config, pkgs, ... }:

{ environment.systemPackages =
    if config.services.xserver.enable then
      [ pkgs.firefox
        pkgs.thunderbird
      ]
    else
      [ ];
}
</programlisting>

</para>

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

<screen>
$ nixos-option services.xserver.enable
true

$ nixos-option boot.kernelModules
[ "tun" "ipv6" "loop" <replaceable>...</replaceable> ]
</screen>

Interactive exploration of the configuration is possible using
<command
xlink:href="https://github.com/edolstra/nix-repl">nix-repl</command>,
a read-eval-print loop for Nix expressions.  It’s not installed by
default; run <literal>nix-env -i nix-repl</literal> to get it.  A
typical use:

<screen>
$ nix-repl '&lt;nixpkgs/nixos>'

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

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

</para>

</section>