This represents the first step in migrating `home.file` to support
arbitrary absolute paths. This is to allow Home Manager to manage
files anywhere, provided the user has sufficient privileges.
For example, with this change the configuration
home.file."test/one".text = "foo";
home.file."/test/two".text = "foo";
will result in the files "$HOME/test/one" and "/test/two",
respectively. Note, a relative file name will still be relative
`$HOME`.
To allow a reasonable transition between the old and new path handling
we introduce the notion of "generation directory layout version". The
version is simply a file `version` within the generation directory
containing a number indicating the version number.
The version 0 (also implied if the version file is missing) indicates
the legacy layout where managed file paths always are relative
`$HOME`.
Version 1 indicates the new layout where managed file paths are
relative `/`.
When profile installation fails during activation we'll print an extra
message that explain that, if the error is due to conflicting
packages, then it may be that the user has a manually installed copy
of the package.
Fixes#1244
Implements a --flake options for build and switch, along with the usual
flake related optons (for lock-files etc).
Configurations in the flake are automatically discovered in the
following order:
1. `outputs.homeConfigurations."$flake-uri"` (the `--flake parameter`)
2. `outputs.homeConfigurations."$USERNAME@$HOSTNAME"`
3. `outputs.homeConfigurations."$USERNAME"`
Make home-manager use default configuration from
~/.config/nixpkgs/flake.nix, if it exists and nothing else is
specified.
Co-authored-by: Nicolas Berbiche <nicolas@normie.dev>
Before the profile directory value would point directly to the build
output in the Nix store. Unfortunately this would cause an infinite
loop if the user's configuration directly or indirectly refers to the
profile directory value.
Fixes#1188
This change makes use of the `extend` function inside `lib` to inject
a new `hm` field containing the Home Manager library functions. This
simplifies use of the Home Manager library in the modules and reduces
the risk of accidental infinite recursion.
PR #994
Unfortunately, using `attrsOf` is not possible since it results in too
eager evaluation. In particular, the
home.sessionVariables = {
FOO = "Hello";
BAR = "${config.home.sessionVariables.FOO} World!";
};
example will cause an infinite recursion.
This commit restores the option type of
- `home.sessionVariables`,
- `pam.sessionVariables`,
- `programs.bash.sessionVariables`, and
- `programs.zsh.sessionVariables`
to `attrs`. It also adds test cases for the above options to avoid
regressions.
Fixes#659
When using the NixOS module we cannot guarantee that the Nix store
will be writable during startup. Installing the user packages through
`nix-env -i` will fail in these cases.
This commit adds a NixOS option `home-manager.useUserPackages` that,
when enabled, installs user packages through the NixOS
users.users.<name?>.packages
option.
Note, when submodule support and external package install is enabled
then the installed packages are not available in `~/.nix-profile`. We
therefore set `home.profileDirectory` directly to the HM profile
packages.
In particular, don't bother attempting to do substitution of the home
files and home generation derivations since these rarely, if ever,
could be substituted.
Fixes#330
It is safest to use the system install of Nix since that will be
compatible with the running nix-daemon and/or databases.
Also add a printout of the used Nix version in the activation script
when running in verbose mode.
Fixes#218.
This is a NixOS module that is intended to be imported into a NixOS
system configuration. It allows the system users to be set up directly
from the system configuration.
The actual profile switch is performed by a oneshot systemd unit per
configured user that acts much like the regular `home-manager switch`
command.
With this implementation, the NixOS module does not work properly with
the `nixos-rebuild build-vm` command. This can be solved by using the
`users.users.<name?>.packages` option to install packages but this
does not work flawlessly with certain Nixpkgs packages. In particular,
for programs using the Qt libraries.
In certain cases it makes sense to override the target username and
home directory. In particular, if you're building a configuration for
a remote profile.
This adds the option `home.emptyActivationPath` that, when enabled,
will cause the activation script to ignore the calling user's `PATH`.
The option is disabled by default to match current behavior but the
intent is to change this in the future to reduce risk of accidental
dependencies of the environment.
Note, we still pull in the user's `PATH` in case the user has defined
their own activation blocks that depend on additional tools.
Eventually this will be deprecated and removed.
See #99.
