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
This enables a module system feature documented here:
https://nixos.org/manual/nixpkgs/stable/index.html#module-system-lib-evalModules-param-class
For example, it allows a mistake to be caught, which is loading a
NixOS module into home-manager. This only works when the offending
module declares what it's for with a `_class` attribute.
It is not expected that users declare the `_type`, because the payoff
is small. It is only expected to be set by generic code, such as
functions or libraries that help with the "publishing" of modules
(e.g. flake-parts, flake-utils).
The class feature has been available in the module system since
https://github.com/NixOS/nixpkgs/pull/197547, merged May 6, 2023. It
has been part of all releases since 23.05-beta. The last NixOS release
that did _not_ support it has been end-of-life for close to a year
now.
Example:
(lib.homeManagerConfiguration {
pkgs = nixpkgs.legacyPackages.x86_64-linux;
modules = [{ _class = "nixos"; imports = [ ./foo.nix ]; }];
}).activation-script
Corresponding error:
error: The module <unknown-file> was imported into homeManager instead of nixos.
(`<unknown-file>` can be improved by also setting `_file`, if known; a
much older feature)
PR #5339
I'm experiencing timeouts for home-manager-$USER.service in my NixOS VM
tests. The NixOS testing framework increases the default timeout from
1m30 to 5m, but since home-manager specifies a timeout, that value wins.
There's no point in having a tight timeout value, so increase it to 5m.
Fixes a regression of GitHub issue #594. Before this commit,
attempting to dynamically configure Home Manager with contents of
nixos's users.users when using the nixos module would result in
infinite recursion.
PR #4368
These (and the `*MD` functions apart from `literalMD`) are now no-ops
in nixpkgs and serve no purpose other than to add additional noise and
potentially mislead people into thinking unmarked DocBook documentation
will still be accepted.
Note that if backporting changes including documentation to 23.05,
the `mdDoc` calls will need to be re-added.
To reproduce this commit, run:
$ NIX_PATH=nixpkgs=flake:nixpkgs/e7e69199f0372364a6106a1e735f68604f4c5a25 \
nix shell nixpkgs#coreutils \
-c find . -name '*.nix' \
-exec nix run -- github:emilazy/nix-doc-munge/98dadf1f77351c2ba5dcb709a2a171d655f15099 \
--strip {} +
$ ./format
This process was automated by [my fork of `nix-doc-munge`]. All
conversions were automatically checked to produce the same DocBook
result when converted back, modulo minor typographical/formatting
differences on the acceptable-to-desirable spectrum.
To reproduce this commit, run:
$ NIX_PATH=nixpkgs=flake:nixpkgs/e7e69199f0372364a6106a1e735f68604f4c5a25 \
nix shell nixpkgs#coreutils \
-c find . -name '*.nix' \
-exec nix run -- github:emilazy/nix-doc-munge/98dadf1f77351c2ba5dcb709a2a171d655f15099 \
{} +
$ ./format
[my fork of `nix-doc-munge`]: https://github.com/emilazy/nix-doc-munge/tree/home-manager
These files all have options that trip up the `nix-doc-munge`
conversion tool for one reason or another (syntax that clashes with
Markdown, options that were already using Markdown syntax despite not
being marked that way, output that differs slightly after conversion,
syntax too elaborate to convert with some cheap regular expressions,
...). Translate them manually and do a little copyediting to options
in the vicinity while we're at it.
This will reduce the system closure size by about 200MB under NixOS by
sharing the glibcLocales package.
When home-manager is installed on Linux without the NixOS module, all
glibc locales are installed, as before.
Resolves: #2333
Starting with state version 22.11 we completely reset the PATH
variable in the activation script. This is to avoid impurities and
unexpected results if the activation script accidentally uses a
command found in the user's PATH.
* Add flake.lock and clean up flake.nix
Add a lockfile to work around https://github.com/NixOS/nix/issues/6541
(and because it's a good idea anyway).
Also use flake-utils, and restrict ourselves to the five platforms
supported by nixpkgs. Otherwise, the IFD for nmd fails on weird
platforms. This fixes `nix flake check`.
Remove the redundant `apps` output, see https://github.com/nix-community/home-manager/pull/2442#issuecomment-1133670487
* nixos,nix-darwin: factor out into a common module
* nixos,nix-darwin: make `home-managers.users` shallowly visible
Make sure the option is included in the NixOS/nix-darwin manual (but the
HM submodule options aren't).
Also add a static description to the HM submodule type so that we don't need to
evaluate the submodules just to build the option manual. This makes
nixos-search able to index the home-manager flake.
Also clean up some TODOs.
* flake: add nmd and nmt
This avoids having to use `pkgs.fetchFromGitLab` in an IFD, which causes
issues when indexing packages with nixos-search because `pkgs` is
instantiated with every platform.
`modulesPath` is usually used with antiquotation
(`"${modulesPath}/some-module.nix"`). Since antiquoted paths are copied
to the Nix store, one must explicitly do `"${toString
modulesPath}/some-module.nix"` to avoid that. Ideally `modulesPath`
should be a string to avoid this. Note that `modulesPath` is already
defined as a string in <home-manager>/modules/default.nix and
<nixpkgs>/nixos/lib/eval-config.nix.
As discussed in this issue:
https://github.com/NixOS/nixpkgs/issues/140879
`types.anything` was never meant to be used for arbitrary modules.
Co-authored-by: Silvan Mosberger <github@infinisil.com>
Having either argument defined based on the OS is a problem when
trying to write generic Nix code.
The current workaround is to use accept both and specify a default
value for each argument:
```
{ config, lib, nixosConfig ? {}, darwinConfig ? {}, ... }:
let
osConfig = nixosConfig // darwinConfig;
in
{
# Do something with `osConfig`
}
```
With this commit, it becomes possible to do the following:
```
{ config, lib, osConfig, ... }:
{
# Do something with `osConfig`
}
```
If the user has a running systemd session, source their environment
from the systemd manager and export a few variables in order to allow
activation scripts to reload applications on the fly.
The list of variables to export is arbitrary and could be extended in
the future.
Fixes#1399, fixes#2112.
One of the things managed by the `home-manager-<username>` unit is the systemd
user directory `.config/systemd/user`. However, this directory needs to be in
place completely before systemd user sessions start up or the user sessions will
come up with an incomplete listing of enabled units, etc.
There was a race condition where nothing prevented
`systemd-user-sessions.service` from starting ahead of the systemd user
directory's initialization completing. This commit makes
`home-manager-<username>` finishes _before_ we start
`systemd-user-sessions.service` to avoid such race condition.
This issue was probably not all that noticeable in most cases, but when using a
non-persistent root config (i.e. tmp on / or
https://grahamc.com/blog/erase-your-darlings) the race condition triggering
causes all kinds of issues on each reboot.
functionTo tries to evaluate functions too quickly and prevents modules
from accessing pkgs argument. fixes#1878.
Co-authored-by: Pacman99 <pachum99@gmail.com>
This allows users of the nixos and nix-darwin module to set shared modules
for all users and extra specialArgs to be available to home-manager modules.
The latter is named extraSpecialArgs just like the argument to
modules/default.nix.
This could be confusing since the the two are independent in code,
but they do mean the same thing so I think the name fits.
Darwin can now refer to the global system configuration if used as a module
through the special `darwinConfig` argument.
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
It is insufficient to install the packages in `home.packages`, it has
to be `home.path`, which includes configured extra package outputs or
profile commands.
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
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.
