Difference between revisions of "Specialisation"
(Mention the --specialisation flag for nixos-rebuild) |
m (Declaring a module is not special "syntax") |
||
(5 intermediate revisions by 5 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. | + | 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 44: | Line 44: | ||
Specialisations 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 specialisations? | Specialisations 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 specialisations? | ||
− | + | Use the conditional `config.specialisation != {}` to declare values for the non-speclised case. For example, you could write a module (as variable, or separat file), imported from `configuration.nix` via `imports = [...]` like this: | |
<syntaxHighlight lang=nix> | <syntaxHighlight lang=nix> | ||
Line 65: | Line 65: | ||
== Runtime activation == | == 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 == |
Latest revision as of 00:07, 1 May 2024
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
Specialisations are defined with the following options [1]: https://search.nixos.org/options?from=0&size=50&sort=relevance&query=specialisation
specialisation = {
chani.configuration = {
services.xserver.desktopManager.plasma5.enable = true;
};
paul = {
inheritParentConfig = false;
configuration = {
system.nixos.tags = [ "paul" ];
services.xserver.desktopManager.gnome.enable = true;
users.users.paul = {
isNormalUser = true;
uid = 1002;
extraGroups = [ "networkmanager" "video" ];
};
services.xserver.displayManager.autoLogin = {
enable = true;
user = "paul";
};
environment.systemPackages = with pkgs; [
dune-release
];
};
};
};
In this example, the chani
specialisation inherits the parent config (that contains the specialisation
directive), but additionally activates the plasma5 desktop. The paul
specialisation on the other hand does not inheritParentConfig
and defines its own one from scratch instead.
Special case: the default non-specialised entry
Specialisations 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 specialisations?
Use the conditional `config.specialisation != {}` to declare values for the non-speclised case. For example, you could write a module (as variable, or separat file), imported from `configuration.nix` via `imports = [...]` like this:
({ lib, config, pkgs, ... }: {
config = lib.mkIf (config.specialisation != {}) {
# Config that should only apply to the default system, not the specialised ones
# example
hardware.opengl.extraPackages = with pkgs; [ vaapiIntel libvdpau-va-gl vaapiVdpau ];
};
})
Boot entries
For every generation of your config, a boot menu entry is generated. When using specialisations, an additional entry is generated for it, per generation.
TODO: how to use grub submenus
Runtime activation
Taking the chani
specialisation from our example, we can activate it at runtime (comparable to nixos-rebuild switch
), by running /run/current-system/specialisation/chani/bin/switch-to-configuration switch
. nixos-rebuild switch
also supports a --specialisation
flag, which we can use like this: nixos-rebuild switch --specialisation chani
.
Further reading
[1] https://www.tweag.io/blog/2022-08-18-nixos-specialisations/
[2] https://discourse.nixos.org/t/nixos-specialisations-how-do-you-use-them/10367/4
[3] https://discourse.nixos.org/t/what-does-mkdefault-do-exactly/9028