mirror of
https://github.com/nix-community/home-manager
synced 2024-11-16 08:09:45 +01:00
36a53d9f26
This process was automated by [my fork of `nix-doc-munge`]. All
conversions were automatically checked to produce the same DocBook
result when converted back, modulo minor typographical/formatting
differences on the acceptable-to-desirable spectrum.
To reproduce this commit, run:
$ NIX_PATH=nixpkgs=flake:nixpkgs/e7e69199f0372364a6106a1e735f68604f4c5a25 \
nix shell nixpkgs#coreutils \
-c find . -name '*.nix' \
-exec nix run -- github:emilazy/nix-doc-munge/98dadf1f77351c2ba5dcb709a2a171d655f15099 \
{} +
$ ./format
[my fork of `nix-doc-munge`]: https://github.com/emilazy/nix-doc-munge/tree/home-manager
83 lines
2.7 KiB
Nix
83 lines
2.7 KiB
Nix
{ config, name, extendModules, lib, ... }:
|
|
|
|
with lib;
|
|
|
|
{
|
|
imports =
|
|
[ (mkRenamedOptionModule [ "specialization" ] [ "specialisation" ]) ];
|
|
|
|
options.specialisation = mkOption {
|
|
type = types.attrsOf (types.submodule {
|
|
options = {
|
|
configuration = mkOption {
|
|
type = let
|
|
extended = extendModules {
|
|
modules = [{
|
|
# Prevent infinite recursion
|
|
specialisation = mkOverride 0 { };
|
|
|
|
# If used inside the NixOS/nix-darwin module, we get conflicting definitions
|
|
# of `name` inside the specialisation: one is the user name coming from the
|
|
# 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;
|
|
}];
|
|
};
|
|
in extended.type;
|
|
default = { };
|
|
visible = "shallow";
|
|
description = lib.mdDoc ''
|
|
Arbitrary Home Manager configuration settings.
|
|
'';
|
|
};
|
|
};
|
|
});
|
|
default = { };
|
|
description = lib.mdDoc ''
|
|
A set of named specialized configurations. These can be used to extend
|
|
your base configuration with additional settings. For example, you can
|
|
have specialisations named "light" and "dark"
|
|
that apply light and dark color theme configurations.
|
|
|
|
::: {.note}
|
|
This is an experimental option for now and you therefore have to
|
|
activate the specialisation by looking up and running the activation
|
|
script yourself. Running the activation script will create a new
|
|
Home Manager generation.
|
|
:::
|
|
|
|
For example, to activate the "dark" specialisation, you can
|
|
first look up your current Home Manager generation by running
|
|
|
|
```console
|
|
$ home-manager generations | head -1
|
|
2022-05-02 22:49 : id 1758 -> /nix/store/jy…ac-home-manager-generation
|
|
```
|
|
|
|
then run
|
|
|
|
```console
|
|
$ /nix/store/jy…ac-home-manager-generation/specialisation/dark/activate
|
|
Starting Home Manager activation
|
|
…
|
|
```
|
|
|
|
::: {.warning}
|
|
Since this option is experimental, the activation process may
|
|
change in backwards incompatible ways.
|
|
:::
|
|
'';
|
|
};
|
|
|
|
config = mkIf (config.specialisation != { }) {
|
|
home.extraBuilderCommands = let
|
|
link = n: v:
|
|
let pkg = v.configuration.home.activationPackage;
|
|
in "ln -s ${pkg} $out/specialisation/${n}";
|
|
in ''
|
|
mkdir $out/specialisation
|
|
${concatStringsSep "\n" (mapAttrsToList link config.specialisation)}
|
|
'';
|
|
};
|
|
}
|