- Add comprehensive documentation for upgrading Home Manager channels.
- Cover channel-based, flake-based, and NixOS module methods.
- Include troubleshooting section and state version updates.
- Update examples for NixOS 25.05 compatibility.
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
Update the documentation to inform users they can create news entries
themselves using `nix run .#create-news-entry` without waiting for
maintainers. This makes the contribution process more self-service
and improves the documentation to match the recently exposed flake
package.
Import-from-derivation (IFD) has problematic performance, and is disabled in
Nixpkgs by policy. It is arguably good practice for libraries to avoid
it whenever possible, as it has poor ergonomics in some cases,
especially with dry builds, as it requires multiple eval+build phases.
As such, prevent its use in Home Manager by default by putting existing
tests that use IFD behind a config. In CI, run a first pass with IFD
disabled, skipping tests without the config. Then run a second pass with
IFD enabled and including tests with the config. This second pass will
also run tests without the config, but they should be cached from the
previous run, so the cost is not double (only eval time should be paid
twice). It’s necessary to change from using NMT’s `run` to `build` as
`run` itself uses IFD.
Of the tests that have the config:
- kitty/theme-to-themeFile: this is a test for deprecated config, and so
should be removed eventually anyway
- podman: the implementation relies on IFD to create individual systemd
units from the derivation output, and so it is not straightforward to
remove the IFD; doing so would require rethinking how the module works
to instead have the systemd unit files included as-is rather than as
individually configured units in the Nix config.
We have stuff that's referenced in CI but not available as flake outputs
to build. Adding default.nix outputs to flake.nix so flake users can
reference them easier.
The current way to define a news entry in Home-Manager is error prone
(since you need to type the date manually) and also it is common cause
of conflicts after merges because all entries are defined in the same
file.
This commit fixes this: we can now create individual news entries for
each new entry. A script `create-news-entry.sh` also helps to create it
in the correct format (with the correct filenames and structure).
This reverts commit 216690777e.
Reverts #6622
Seems to be causing issues for other users, though. Will revert and we can try again with some tests in place.
Pushing users.users.<name>.packages from matching home-manager users leads to a circular dependency when
one attribute set is calculated from the other.
A configuration pull approach replaces the previous one to break up the circular dependency. This new approach
allows more flexibility in configuring both option sets, including calculating from each other.
EXAMPLE;
```nix
{lib, /* custom arg */ flake, config, ...}: {
home-manager.useUserPackages = true;
home-manager.users = builtins.intersectAttrs (lib.filterAttrs (_: v: v.isNormalUser) config.users.users) (flake.outputs.homeModules.users);
}
```
EXAMPLE;
```nix
{lib, /* custom arg */ flake, config, ...}: {
home-manager.useUserPackages = true;
home-manager.users = { inherit (flake.outputs.homeModules.users) demo-user; };
users.users = lib.mapAttrs (_: _: { isNormalUser = true; }) (lib.filterAttrs (_: v: v.programs.git.enable) config.home-manager.users);
}
```
fixes#594
* options-manual: Remove `users` option set from documentation
The option declaration `users.users` is owned by the upstream
nixos modules and should not be documented by home-manager.
Home-manager declares an incomplete/partial option definition for
`users.users` that cannot be documented without the full definition from
the nixos modules. This partial definition is removed from the options
set while generating documentation for the home-manager nixos module.
This reverts commit 066ba0c5cf. After
further discussion, we want to maintain this as the naming scheme going
forward to be similar to standards that have been trying to be
implemented in naming configurations and modules.
Add a flake-parts module, output as flakeModules.home-manager and flakeModules.default.
The module defines options for flake.homeModules and flake.homeConfigurations, based on the respective nixos equivalents; flake.nixosModules and flake.nixosConfigurations.
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
After migrating to nixos-render-docs, the extension move to .xtml.
Unfortunately, this broke links to the previous Options Page.
This patch provides a basic redirect support to the new Options Page.
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
