1
0
Fork 0
mirror of https://github.com/nix-community/home-manager synced 2024-11-27 05:29:46 +01:00
home-manager/docs/manual/internals/activation.md
Robert Helgesson 4aa9eb327d
WIP home-manager: avoid profile management during activation
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
2024-06-22 15:15:55 +02:00

2.1 KiB
Raw Permalink Blame History

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.