The current behavior of `home.file` is inconsistent when handling
recursive file with another, overlapping, non-recursive file.
Specifically, consider a configuration
```nix
home.file = {
"foo" = { source = ./foo; recursive = true; };
"foo/bar".text = "some other file";
};
```
where `./foo` is a directory containing a file `bar`. Switching to
this configuration will result in the `./foo` directory being
recursively symlinked while the "foo/bar" entry is ignored. Note,
building the home files derivation does log
> File conflict for file 'foo/bar'
On the other hand, the supposedly equivalent configuration
```nix
home.file = {
"foo" = { source = ./foo; recursive = true; };
abc = { target = "foo/bar"; text = "some other file"; };
};
```
results in the `./foo` directory not being recursively symlinked,
i.e., only the file `foo/bar` shows up in the built configuration.
This time the home files build log contains
> File conflict for file 'foo'
This commit makes the behavior more consistent in that we always
handle the file in a unified manner. The conflict resolution is
offered in three flavors, "ignore", "error", and "override" indicating
whether the recursively symlinked file wins, the entire build errors
out, and the regularly symlinked file wins.
The current default is "ignore" since it is the resolution that most
closely matches the current behavior, at least when the file attribute
name is used as the target path.
The other two resolutions can be chosen by setting the
`home.fileOverlapResolution` option, which is set as invisible due to
its experimental nature.
This is mainly to unify the error messages for more convenient and
consistent translation. Also allows somewhat more convenience if
additional checks are needed.
Stopping or restarting the service will destroy open Ghostty sessions,
potentially disrupting work. This change ensures that we leave the
existing service untouched.
Fixes#8485
In the code base, there are lots of configurations locally guarded by
`stdenv.hostPlatform.is(Darwin|Linux)` despite the targeted options
already being guarded. Examples for these targeted options are:
- `systemd.user.*`: globally guarded by `systemd.user.enable`.
- `launchd.*`: globally guarded by `launchd.enable`.
- `lib.hm.darwin.assertInterval`: only effective on Darwin.
These local guards are an antipattern since they weaken the global
guards. Furthermore, they hamper readability. This series of commits
remove instances of these local guards.
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.
Robert Helgesson