1
0
Fork 0
mirror of https://github.com/nix-community/home-manager synced 2024-11-18 00:59:44 +01:00
home-manager/modules/misc/specialisation.nix
Emily 9f9e277b60 treewide: remove now-redundant lib.mdDoc calls
These (and the `*MD` functions apart from `literalMD`) are now no-ops
in nixpkgs and serve no purpose other than to add additional noise and
potentially mislead people into thinking unmarked DocBook documentation
will still be accepted.

Note that if backporting changes including documentation to 23.05,
the `mdDoc` calls will need to be re-added.

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 \
      --strip {} +
    $ ./format
2023-07-17 18:49:09 +01:00

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 = ''
Arbitrary Home Manager configuration settings.
'';
};
};
});
default = { };
description = ''
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/jyac-home-manager-generation
```
then run
```console
$ /nix/store/jyac-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)}
'';
};
}