| Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
Allows setting every locale option independently. Also fixes `LC_`
order to match the order of `locale` command output for better
reference.
PR #1278
|
|
This removes the use of the non-deterministic function
`builtins.getEnv` for state version ā„ 20.09.
PR #1269
|
|
|
|
This is an internal option for adding additional code to
`hm-session-vars.sh`.
|
|
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
|
|
Also improve documentation and add an example.
|
|
|
|
Also, actually use it in the call to setxkbmap.
|
|
Also default these options to `null` for state version ā„ 19.09.
Fixes #811
Suggested-by: Sean Marshallsay <srm.1708@gmail.com>
|
|
|
|
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 set to `null` then the `xsession` module will not attempt to
manage the keyboard settings.
|
|
|
|
Instead use `runCommand`, which by default uses `stdenvNoCC` resulting
in a reduced dependency footprint.
Fixes #612
|
|
|
|
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.
|
|
This _internal_ option indicates extra commands that should be run in
the `postBuild` step of the profile environment build.
Fixes #386
|
|
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.
|
|
|
|
This is a file containing all session variables exported using a
Bourne-compatible syntax.
|
|
|
|
|
|
This avoids issues when starting the activation script somewhere
inaccessible.
|
|
|
|
Also replace all imports of `dag.nix` by the entry in `config.lib`.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Technically not necessary but it was a bit silly to leave out this
important directory from the generation directory. This also makes it
more convenient to browse the installed packages after a
`home-managerĀ build`.
|
|
Using a relative path prevents the latest version from being garbage
collected.
|
|
|
|
|
|
With --ignore-fail-on-non-empty, non-emptiness is the only failure
that gets ignored by rmdir. In the case that rmdir reaches $HOME and
considers deleting it, it will detect insufficient permissions and
subsequently exit with an error, even if $HOME is not empty.
Prevent this by calling rmdir with a relative path that excludes
$HOME.
|
|
|
|
We must only follow the symbolic link once (i.e., not use the `-e`
option) since otherwise the pattern will not match when
`home.file.xyz.source` is a directory.
|