This removes the possibility of running `home-manager rollback`. It
was added by mistake at some point and has never worked since it
immediately calls a non-existent function `doRollback`.
This option allows a user to inject default applications directly from
a list of specified packages. It was previously possible to do this,
but only through import from derivation.
It was a bit too ambitious to also remove production of the gcroot, we
need it to keep track of the currently active Home Manager
configuration.
Fixes#7583
The poison module is intended to catch cases where the documentation
depends on the user's configuration. We want to keep such dependencies
to a minimum as it increases the risk of documentation rebuilds and
confusion caused by documentation being different depending on the
source.
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 --specialisation NAME`, which switches to the
named specialisation. While it was previously possible to accomplish
this by manually running the specialisation activate script, 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
These were removed as part of dead code removal, but they are actually
needed in the integration tests for comparing with the configuration
generated by the installation.
This removes the automatic update of the Home Manager packaging in
<https://gitlab.com/rycee/nur-expressions/>. That setup is very old
and brittle, it should therefore not be used.
Instead of having to manually stub packages that should not be
downloaded we instead automatically stub all packages (except a small
list of whitelisted ones). Tests can re-introduce the real package by
using the `realPkgs` module argument.
Having the tests available in the main Nix Flake introduces
unnecessary evaluation for non-developer users and, worse, a
dependency on the nmt library.
Fixes#6354
This commit separates profile management (setting profile and creating
GC root) from file management (removing and adding managed files
within the user's home directory).
This is a step towards deprecating profile management within the
activation script, instead relying on the caller of the activation
script managing the profile.
The initExtra code is executed after systemd graphical-session.target
starts, which means graphical applications started by
graphical-session.target cannot get these X settings.
The initExtra code is executed after systemd graphical-session.target
starts, which means graphical applications started by
graphical-session.target cannot get these X settings.
They have been broken for a long time now and makes the PR flow quite
cumbersome. Thus we disable them until somebody is able to get them to
work again.
Robert Helgesson