Jump to content

Specialisation: Difference between revisions

From Official NixOS Wiki
imported>Anoadragon453
m fix typo in Previously
Noewaeda (talk | contribs)
mNo edit summary
 
(16 intermediate revisions by 11 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}}
{{low quality|References need to use <nowiki><cite></nowiki> instead of just being numbers in brackets.}}


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.
Specialisations allow you to define variations of your system configuration. For instance, if you don't usually use GPU, you might create a base system with your GPU disabled and create a dedicated specialisation with Nvidia/AMD drivers installed. Then, during boot, you can choose which configuration you want to boot into this time.
 
Previously this feature was called "children" because a specialised configuration is defined by its "parent" configuration. Afterwards it was called "nesting", because this feature essentially allows nested configurations. Finally it was renamed to todays "specialisation". [2]


== Config ==
== Config ==


Specialisations are defined with the following options [1]: https://search.nixos.org/options?from=0&size=50&sort=relevance&query=specialisation
Specialisations are defined with the following options<ref>https://www.tweag.io/blog/2022-08-18-nixos-specialisations/</ref>: https://search.nixos.org/options?from=0&size=50&sort=relevance&query=specialisation


<syntaxHighlight lang=nix>
<syntaxHighlight lang=nix>
specialisation = {
specialisation = {
   chani.configuration = {
   chani.configuration = {
     services.xserver.desktopManager.plasma5.enable = true;
     services.desktopManager.plasma6.enable = true;
   };
   };


Line 19: Line 18:
     configuration = {
     configuration = {
       system.nixos.tags = [ "paul" ];
       system.nixos.tags = [ "paul" ];
       services.xserver.desktopManager.gnome.enable = true;
       services.desktopManager.gnome.enable = true;
       users.users.paul = {
       users.users.paul = {
         isNormalUser = true;
         isNormalUser = true;
Line 25: Line 24:
         extraGroups = [ "networkmanager" "video" ];
         extraGroups = [ "networkmanager" "video" ];
       };
       };
       services.xserver.displayManager.autoLogin = {
       services.displayManager.autoLogin = {
         enable = true;
         enable = true;
         user = "paul";
         user = "paul";
Line 36: Line 35:
};</syntaxHighlight>
};</syntaxHighlight>


In this example, the <code>chani</code> specialisation inherits the parent config (that contains the <code>specialisation</code> directive), but additionally activates the plasma5 desktop. The <code>paul</code> specialisation on the other hand does not <code>inheritParentConfig</code> and defines its own one from scratch instead.  
In this example, the <code>chani</code> specialisation inherits the parent configuration (which contains the <code>specialisation</code> directive), but additionally activates the <code>plasma6</code> desktop. The <code>paul</code> specialisation does not inherit the parent configuration, and defines its own configuration from scratch instead.  


{{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 &#61; false;</code> in an overwritable manner using <code>mkDefault</code> and similar [3]: <code>services.xserver.desktopManager.plasma5.enable &#61; 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.desktopManager.plasma6.enable &#61; false;</code> in an overwritable manner using <code>mkDefault</code> and similar<ref>https://discourse.nixos.org/t/what-does-mkdefault-do-exactly/9028</ref>: <code>services.desktopManager.plasma6.enable &#61; lib.mkDefault false;</code>}}


== Special case: the default non-specialised entry ==
== 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?
Specialisations will receive options in addition to your default configuration. If you want to have options in your default configuration that shouldn't be pulled by the specialisations, use the conditional <code>config.specialisation != {}</code> to declare values for the non-specialised case.


There is a specific syntax to declare options that apply to the case environment "not specialised" and that won't be pulled by other specialisations. You need to wrap the options into a new file that is imported into your configuration.nix file
For example, you could write a module (as a variable, or a separate file), imported from <code>configuration.nix</code> via <code>imports = [...]</code> like this:


<syntaxHighlight lang=nix>
<syntaxHighlight lang=nix>
Line 52: Line 51:


     # example
     # example
     hardware.opengl.extraPackages = with pkgs; [ vaapiIntel libvdpau-va-gl vaapiVdpau ];
     hardware.opengl.extraPackages = with pkgs; [ vaapiIntel vaapiVdpau ];
   };
   };
})
})
</syntaxHighlight>
</syntaxHighlight>


== Boot entries ==
However, if there are no specialisations defined, then <code>config.specialisation != {}</code> always evaluates to <code>false</code>.


For every generation of your config, a boot menu entry is generated. When using specialisations, an additional entry is generated for it, per generation.
== Activating a specialisation ==


TODO: how to use grub submenus
After rebuilding your system, you can choose a specialisation during boot. It's also possible to switch into a specialisation at runtime - following the example above, you would run:


== Activation scripts ==
<syntaxHighlight lang=console>
$ nixos-rebuild switch --specialisation chani
</syntaxHighlight>


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>/nix/var/nix/profiles/system/specialisation/chani/bin/switch-to-configuration switch</code>.
Not all configurations can be fully switched into at runtime. For example, if your specialisation uses a different kernel, switching into it will not actually reload the kernel, but if you were to restart your computer and pick the specialisation from the boot menu, the alternative kernel would be loaded.


== Further reading ==
== Further reading ==


[1] https://www.tweag.io/blog/2022-08-18-nixos-specialisations/
* https://discourse.nixos.org/t/nixos-specialisations-how-do-you-use-them/
 
[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
{{references}}

Latest revision as of 23:50, 22 September 2026

☶︎
This article or section needs to be expanded. Further information may be found in the related discussion page. Please consult the pedia article metapage for guidelines on contributing.
⍼︎
This article or section is of low quality. References need to use <cite> instead of just being numbers in brackets. Further information may be found in the related discussion page. Editors that are knowledgeable in this area are encouraged to expand it, otherwise this page could become a candidate for deletion.

Specialisations allow you to define variations of your system configuration. For instance, if you don't usually use GPU, you might create a base system with your GPU disabled and create a dedicated specialisation with Nvidia/AMD drivers installed. Then, during boot, you can choose which configuration you want to boot into this time.

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.desktopManager.plasma6.enable = true;
  };

  paul = {
    inheritParentConfig = false;
    configuration = {
      system.nixos.tags = [ "paul" ];
      services.desktopManager.gnome.enable = true;
      users.users.paul = {
        isNormalUser = true;
        uid = 1002;
        extraGroups = [ "networkmanager" "video" ];
      };
      services.displayManager.autoLogin = {
        enable = true;
        user = "paul";
      };
      environment.systemPackages = with pkgs; [
        dune-release
      ];
    };
  };
};

In this example, the chani specialisation inherits the parent configuration (which contains the specialisation directive), but additionally activates the plasma6 desktop. The paul specialisation does not inherit the parent configuration, and defines its own configuration from scratch instead.

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 chani example, the parent configuration could define services.desktopManager.plasma6.enable = false; in an overwritable manner using mkDefault and similar[2]: services.desktopManager.plasma6.enable = lib.mkDefault false;

Special case: the default non-specialised entry

Specialisations will receive options in addition to your default configuration. 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-specialised case.

For example, you could write a module (as a variable, or a separate 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 vaapiVdpau ];
  };
})

However, if there are no specialisations defined, then config.specialisation != {} always evaluates to false.

Activating a specialisation

After rebuilding your system, you can choose a specialisation during boot. It's also possible to switch into a specialisation at runtime - following the example above, you would run:

$ nixos-rebuild switch --specialisation chani

Not all configurations can be fully switched into at runtime. For example, if your specialisation uses a different kernel, switching into it will not actually reload the kernel, but if you were to restart your computer and pick the specialisation from the boot menu, the alternative kernel would be loaded.

Further reading

References