2023-02-28 22:22:22 +01:00
|
|
|
{ config, name, extendModules, lib, ... }:
|
2022-04-18 21:44:20 +02:00
|
|
|
|
|
|
|
with lib;
|
|
|
|
|
|
|
|
{
|
2023-06-13 08:44:30 +02:00
|
|
|
imports =
|
|
|
|
[ (mkRenamedOptionModule [ "specialization" ] [ "specialisation" ]) ];
|
|
|
|
|
|
|
|
options.specialisation = mkOption {
|
2022-04-18 21:44:20 +02:00
|
|
|
type = types.attrsOf (types.submodule {
|
|
|
|
options = {
|
|
|
|
configuration = mkOption {
|
|
|
|
type = let
|
2023-02-28 22:22:22 +01:00
|
|
|
extended = extendModules {
|
|
|
|
modules = [{
|
|
|
|
# Prevent infinite recursion
|
2023-06-13 08:44:30 +02:00
|
|
|
specialisation = mkOverride 0 { };
|
2023-02-28 22:22:22 +01:00
|
|
|
|
|
|
|
# If used inside the NixOS/nix-darwin module, we get conflicting definitions
|
2023-06-13 08:44:30 +02:00
|
|
|
# of `name` inside the specialisation: one is the user name coming from the
|
2023-02-28 22:22:22 +01:00
|
|
|
# NixOS module definition and the other is `configuration`, the name of this
|
|
|
|
# option. Thus we need to explicitly wire the former into the module arguments.
|
|
|
|
# See discussion at https://github.com/nix-community/home-manager/issues/3716
|
|
|
|
_module.args.name = mkForce name;
|
|
|
|
}];
|
|
|
|
};
|
2022-04-18 21:44:20 +02:00
|
|
|
in extended.type;
|
|
|
|
default = { };
|
|
|
|
visible = "shallow";
|
2023-07-02 01:45:18 +02:00
|
|
|
description = ''
|
2022-04-18 21:44:20 +02:00
|
|
|
Arbitrary Home Manager configuration settings.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
};
|
|
|
|
});
|
|
|
|
default = { };
|
2023-07-02 01:45:18 +02:00
|
|
|
description = ''
|
2022-04-18 21:44:20 +02:00
|
|
|
A set of named specialized configurations. These can be used to extend
|
|
|
|
your base configuration with additional settings. For example, you can
|
2023-07-01 00:35:51 +02:00
|
|
|
have specialisations named "light" and "dark"
|
|
|
|
that apply light and dark color theme configurations.
|
2022-04-18 21:44:20 +02:00
|
|
|
|
2023-07-01 00:35:51 +02:00
|
|
|
::: {.note}
|
|
|
|
This is an experimental option for now and you therefore have to
|
2023-06-13 08:44:30 +02:00
|
|
|
activate the specialisation by looking up and running the activation
|
2023-07-01 00:35:51 +02:00
|
|
|
script yourself. Running the activation script will create a new
|
2022-04-18 21:44:20 +02:00
|
|
|
Home Manager generation.
|
2023-07-01 00:35:51 +02:00
|
|
|
:::
|
2022-04-18 21:44:20 +02:00
|
|
|
|
2023-07-01 00:35:51 +02:00
|
|
|
For example, to activate the "dark" specialisation, you can
|
2022-04-18 21:44:20 +02:00
|
|
|
first look up your current Home Manager generation by running
|
|
|
|
|
2023-07-01 00:35:51 +02:00
|
|
|
```console
|
|
|
|
$ home-manager generations | head -1
|
|
|
|
2022-05-02 22:49 : id 1758 -> /nix/store/jy…ac-home-manager-generation
|
|
|
|
```
|
2022-04-18 21:44:20 +02:00
|
|
|
|
|
|
|
then run
|
|
|
|
|
2023-07-01 00:35:51 +02:00
|
|
|
```console
|
|
|
|
$ /nix/store/jy…ac-home-manager-generation/specialisation/dark/activate
|
|
|
|
Starting Home Manager activation
|
|
|
|
…
|
|
|
|
```
|
2022-04-18 21:44:20 +02:00
|
|
|
|
2023-07-01 00:35:51 +02:00
|
|
|
::: {.warning}
|
|
|
|
Since this option is experimental, the activation process may
|
2022-04-18 21:44:20 +02:00
|
|
|
change in backwards incompatible ways.
|
2023-07-01 00:35:51 +02:00
|
|
|
:::
|
2022-04-18 21:44:20 +02:00
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
2023-06-13 08:44:30 +02:00
|
|
|
config = mkIf (config.specialisation != { }) {
|
2022-04-18 21:44:20 +02:00
|
|
|
home.extraBuilderCommands = let
|
|
|
|
link = n: v:
|
|
|
|
let pkg = v.configuration.home.activationPackage;
|
2023-06-13 08:44:30 +02:00
|
|
|
in "ln -s ${pkg} $out/specialisation/${n}";
|
2022-04-18 21:44:20 +02:00
|
|
|
in ''
|
2023-06-13 08:44:30 +02:00
|
|
|
mkdir $out/specialisation
|
|
|
|
${concatStringsSep "\n" (mapAttrsToList link config.specialisation)}
|
2022-04-18 21:44:20 +02:00
|
|
|
'';
|
|
|
|
};
|
|
|
|
}
|