Specialisation: Difference between revisions
imported>Rapenne-s add the non-specialized case |
|||
| (6 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
{{Expansion|Configuration with and for GRUB could use explaining here}} | {{Expansion|Configuration with and for GRUB could use explaining here}} | ||
Specialisations allow you | Specialisations allow you to define variations of your config within itself (even completely different ones). Within a generation of your config, you can then choose between specialisations at boot-time or switch them at runtime using activation scripts. | ||
Previously this feature was called "children" because a specialised configuration is defined by its "parent" configuration. Later, it was called "nesting", because this feature essentially allows nested configurations. Finally, it was renamed to todays "specialisation". [2] | |||
== Config == | == Config == | ||
| Line 40: | Line 40: | ||
{{Note|At times, you may want to overwrite values in specialisations which you have already defined in your parent configuration. To solve this problem in <code>chani</code> example, the parent configuration could define <code>services.xserver.desktopManager.plasma5.enable = false;</code> in an overwritable manner using <code>mkDefault</code> and similar [3]: <code>services.xserver.desktopManager.plasma5.enable = mkDefault false;</code>}} | {{Note|At times, you may want to overwrite values in specialisations which you have already defined in your parent configuration. To solve this problem in <code>chani</code> example, the parent configuration could define <code>services.xserver.desktopManager.plasma5.enable = false;</code> in an overwritable manner using <code>mkDefault</code> and similar [3]: <code>services.xserver.desktopManager.plasma5.enable = mkDefault false;</code>}} | ||
== Special case: the default non- | == Special case: the default non-specialized entry == | ||
Specializations are receiving options in addition to your default configuration, but what if you want to have options in your default configuration that shouldn't be pulled by the specializations? | |||
Use the conditional <code>config.specialisation != {}</code> to declare values for the non-specialized case. For example, you could write a module (as variable, or separate file), imported from <code>configuration.nix</code> via <code>imports = [...]</code> like this: | |||
<syntaxHighlight lang=nix> | <syntaxHighlight lang=nix> | ||
| Line 52: | Line 52: | ||
# example | # example | ||
hardware.opengl.extraPackages = with pkgs; [ vaapiIntel | hardware.opengl.extraPackages = with pkgs; [ vaapiIntel vaapiVdpau ]; | ||
}; | }; | ||
}) | }) | ||
| Line 63: | Line 63: | ||
TODO: how to use grub submenus | TODO: how to use grub submenus | ||
== | == Runtime activation == | ||
Taking the <code>chani</code> specialisation from our example, we can activate it at runtime (comparable to <code>nixos-rebuild switch</code>), by running <code>/ | Taking the <code>chani</code> specialisation from our example, we can activate it at runtime (comparable to <code>nixos-rebuild switch</code>), by running <code>/run/current-system/specialisation/chani/bin/switch-to-configuration switch</code>. <code>nixos-rebuild switch</code> also supports a <code>--specialisation</code> flag, which we can use like this: <code>nixos-rebuild switch --specialisation chani</code>. | ||
== Further reading == | == Further reading == | ||