b0ccd6dd16
This reverts commit ea6e8775bd69e4676c623a85c39f1da540d29ad1. The new format is not an improvement.
100 lines
3.5 KiB
XML
100 lines
3.5 KiB
XML
<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-option-definitions">
|
|
<title>Option Definitions</title>
|
|
|
|
<para>
|
|
Option definitions are generally straight-forward bindings of values to
|
|
option names, like
|
|
<programlisting>
|
|
config = {
|
|
services.httpd.enable = true;
|
|
};
|
|
</programlisting>
|
|
However, sometimes you need to wrap an option definition or set of option
|
|
definitions in a <emphasis>property</emphasis> to achieve certain effects:
|
|
</para>
|
|
|
|
<simplesect xml:id="sec-option-definitions-delaying-conditionals">
|
|
<title>Delaying Conditionals</title>
|
|
<para>
|
|
If a set of option definitions is conditional on the value of another
|
|
option, you may need to use <varname>mkIf</varname>. Consider, for instance:
|
|
<programlisting>
|
|
config = if config.services.httpd.enable then {
|
|
environment.systemPackages = [ <replaceable>...</replaceable> ];
|
|
<replaceable>...</replaceable>
|
|
} else {};
|
|
</programlisting>
|
|
This definition will cause Nix to fail with an “infinite recursion”
|
|
error. Why? Because the value of
|
|
<option>config.services.httpd.enable</option> depends on the value being
|
|
constructed here. After all, you could also write the clearly circular and
|
|
contradictory:
|
|
<programlisting>
|
|
config = if config.services.httpd.enable then {
|
|
services.httpd.enable = false;
|
|
} else {
|
|
services.httpd.enable = true;
|
|
};
|
|
</programlisting>
|
|
The solution is to write:
|
|
<programlisting>
|
|
config = mkIf config.services.httpd.enable {
|
|
environment.systemPackages = [ <replaceable>...</replaceable> ];
|
|
<replaceable>...</replaceable>
|
|
};
|
|
</programlisting>
|
|
The special function <varname>mkIf</varname> causes the evaluation of the
|
|
conditional to be “pushed down” into the individual definitions, as if
|
|
you had written:
|
|
<programlisting>
|
|
config = {
|
|
environment.systemPackages = if config.services.httpd.enable then [ <replaceable>...</replaceable> ] else [];
|
|
<replaceable>...</replaceable>
|
|
};
|
|
</programlisting>
|
|
</para>
|
|
</simplesect>
|
|
|
|
<simplesect xml:id="sec-option-definitions-setting-priorities">
|
|
<title>Setting Priorities</title>
|
|
<para>
|
|
A module can override the definitions of an option in other modules by
|
|
setting a <emphasis>priority</emphasis>. All option definitions that do not
|
|
have the lowest priority value are discarded. By default, option definitions
|
|
have priority 1000. You can specify an explicit priority by using
|
|
<varname>mkOverride</varname>, e.g.
|
|
<programlisting>
|
|
services.openssh.enable = mkOverride 10 false;
|
|
</programlisting>
|
|
This definition causes all other definitions with priorities above 10 to be
|
|
discarded. The function <varname>mkForce</varname> is equal to
|
|
<varname>mkOverride 50</varname>.
|
|
</para>
|
|
</simplesect>
|
|
|
|
<simplesect xml:id="sec-option-definitions-merging">
|
|
<title>Merging Configurations</title>
|
|
<para>
|
|
In conjunction with <literal>mkIf</literal>, it is sometimes useful for a
|
|
module to return multiple sets of option definitions, to be merged together
|
|
as if they were declared in separate modules. This can be done using
|
|
<varname>mkMerge</varname>:
|
|
<programlisting>
|
|
config = mkMerge
|
|
[ # Unconditional stuff.
|
|
{ environment.systemPackages = [ <replaceable>...</replaceable> ];
|
|
}
|
|
# Conditional stuff.
|
|
(mkIf config.services.bla.enable {
|
|
environment.systemPackages = [ <replaceable>...</replaceable> ];
|
|
})
|
|
];
|
|
</programlisting>
|
|
</para>
|
|
</simplesect>
|
|
</section>
|