mirror of
https://github.com/nix-community/home-manager
synced 2024-11-16 16:19:44 +01:00
9f9e277b60
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
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 = ''
|
|
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/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)}
|
|
'';
|
|
};
|
|
}
|