Specialisation - Revision history

Zeal: It might be more intuitive to add `lib.` to the `mkDefault`-value for users copying this code.

2025-10-19T02:33:32Z

It might be more intuitive to add `lib.` to the `mkDefault`-value for users copying this code.

← Older revision		Revision as of 02:33, 19 October 2025
Line 37:		Line 37:
	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 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.

	{{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 = lib.mkDefault false;</code>}}

	== Special case: the default non-specialized entry ==		== Special case: the default non-specialized entry ==

SigmaSquadron: lowquality

2025-04-17T17:49:22Z

lowquality

← Older revision		Revision as of 17:49, 17 April 2025
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 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 specialization with Nvidia/AMD drivers installed - later, during boot, you can choose which configuration you want to boot into this time.		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 specialization with Nvidia/AMD drivers installed - later, during boot, you can choose which configuration you want to boot into this time.

Fin444 at 01:26, 7 November 2024

2024-11-07T01:26:26Z

← Older revision		Revision as of 01:26, 7 November 2024
Line 54:		Line 54:
	})		})
	</syntaxHighlight>		</syntaxHighlight>

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

	== Activating a specialization ==		== Activating a specialization ==

Patryk27 at 09:48, 20 October 2024

2024-10-20T09:48:07Z

← Older revision		Revision as of 09:48, 20 October 2024
Line 57:		Line 57:
	== Activating a specialization ==		== Activating a specialization ==

	After rebuilding your system, you can choose a specialisation during boot; ~~but~~ it's also possible to switch into a specialisation at runtime - following the example above, we'd run:		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, we'd run:

	<syntaxHighlight lang=console>		<syntaxHighlight lang=console>
Line 63:		Line 63:
	</syntaxHighlight>		</syntaxHighlight>

	Note that not all configurations can be switched into at runtime - e.g. if your specialization 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 get loaded).		Note that not all configurations can be fully switched into at runtime - e.g. if your specialization 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 get loaded).

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

Patryk27: /* Runtime activation */

2024-10-20T09:43:57Z

Runtime activation

← Older revision		Revision as of 09:43, 20 October 2024
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 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 specialization with Nvidia/AMD drivers installed - later, 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. Later, it was called "nesting", because this feature essentially allows nested configurations. Finally, it was renamed to todays "specialisation". ~~[2]~~

	== Config ==		== Config ==
Line 57:		Line 55:
	</syntaxHighlight>		</syntaxHighlight>

	== ~~Boot entries~~ ==		== Activating a specialization ==

	~~For every generation of~~ your ~~config~~, a boot ~~menu entry is generated. When using specialisations, an additional entry is generated for~~ it, ~~per generation.~~		After rebuilding your system, you can choose a specialisation during boot; but it's also possible to switch into a specialisation at runtime - following the example above, we'd run:

	~~TODO: how to use grub submenus~~		<syntaxHighlight lang=console>
			$ nixos-rebuild switch --specialisation chani
	~~== Runtime activation ==~~		</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>/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>~~.		Note that not all configurations can be switched into at runtime - e.g. if your specialization 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 get loaded).

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

Sandro: /* Special case: the default non-specialized entry */

2024-07-09T14:31:04Z

Special case: the default non-specialized entry

← Older revision		Revision as of 14:31, 9 July 2024
Line 52:		Line 52:

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

Mic92: imported from old wiki

2024-05-02T04:40:33Z

imported from old wiki

← Older revision		Revision as of 04:40, 2 May 2024
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-~~specialised~~ entry ==		== Special case: the default non-specialized 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~~?		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?

	~~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~~		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>

imported>PhilTaken: fix an incorrect path to the specialisation switch

2023-11-20T14:40:49Z

fix an incorrect path to the specialisation switch

← Older revision		Revision as of 14:40, 20 November 2023
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>/~~nix/var/nix/profiles~~/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>.		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 ==

imported>Skylark: /* intro */ punctuation

2023-10-16T15:55:21Z

intro: punctuation

← Older revision		Revision as of 15:55, 16 October 2023
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, 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 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. ~~Afterwards~~ it was called "nesting", because this feature essentially allows nested configurations. Finally it was renamed to todays "specialisation". [2]		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 ==

imported>Keksgesicht at 21:01, 14 October 2023

2023-10-14T21:01:31Z

← Older revision		Revision as of 21:01, 14 October 2023
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>/nix/var/nix/profiles/system/specialisation/chani/bin/switch-to-configuration switch</code>. <code>nixos-rebuild switch</code> also supports a <code>--~~specalisation~~</code> flag, which we can use like this: <code>nixos-rebuild switch --specialisation chani</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>/nix/var/nix/profiles/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 ==