This commit deprecates profile management from the activation script. The profile management is instead the responsibility of the driving software, for example, the `home-manager` tool in the case of standalone installs. The legacy behavior is still available for backwards compatibility but may be removed in the future. The new behavior resolves (or moves us closer to resolving) a number of long standing open issues: - `home-manager switch --rollback`, which performs a rollback to the previous Home Manager generation before activating. While it was previously possible to accomplish this by activating an old generation, it did always create a new profile generation. This option has been implemented as part of this commit. - `home-manager switch --test`, which activates the configuration but does not create a new profile generation. This option has _not_ been implemented here since it relies on the current configuration being activated on login, which we do not currently do. - When using the "Home Manager as a NixOS module" installation method we previously created an odd `home-manager` per-user "shadow profile" for the user. This is no longer necessary. This has been implemented as part of this commit. Fixes #3450
2.1 KiB
Activation
Activating a Home Manager configuration ensures that the built
configuration is introduced into the user's environment. The
activation is performed by a suitably named script
{command}activate
. This script is generated as part of the
configuration build and will be placed in the root of the build
output.
The activation script is implemented in the Bash language and consists of initialization code followed by a number of activation script blocks. These blocks are specified using the home.activation option. The blocks may have dependencies among themselves and the generated activation script will contain the blocks serialized such that the dependencies are satisfied. A dependency cycle causes a failure when the configuration is built.
Historically, the activation script has been responsible for creating
a new generation of the home-manager
Nix profile. The more modern
way, however, is to let the activation driver – that is, the
software calling the activation script – manage the profile. Indeed,
in some cases we may not have a home-manager
profile at all! This is
the case when Home Manager is used as a NixOS or nix-darwin module, in
these cases the system profile will contain references to the
corresponding Home Manager configurations.
Note, to maintain backwards compatibility, the old activation script
behavior is still the default. To choose the new mode of operation you
have to call the activation script with the command line option
--driver-version 1
. The old behavior is available using
--driver-version 0
, or simply omit it entirely.
Unfortunately, driver software need to support both modes of operation
for the time being since a user may wish to activate an old generation
that contains an activation script that does not support
--driver-version
. To determine whether support is available, check
the {file}gen-version
file in the configuration build output root.
If the file is missing then the activation script does not support
--driver-version
. If the file exists and contains the integer 1 or
higher, then --driver-version 1
is supported.