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
The beets package no longer has the "enableCheck" option so this was
confusing. Also the word override was used to mean two different
things so I modified the FAQ to use the word "change" and linked to
documentation regarding package overrides.
Turns out pulling nmt and nmd from Nixpkgs causes an IFD, even when
the packages are fixed-output derivations.
Thus, since Sourcehut is up and well, we can revert to simply fetching
nmd and nmt directly.
See discussion in <https://github.com/nix-community/home-manager/pull/4884>.
This adds a Boolean option `uninstall`. When enabled this option will
reset side-effecting configurations to their "empty" state. The intent
is that this will cause the activation script to remove all managed
files and packages.
Doing it this way should hopefully be more robust than the previous
solution. It also allows a somewhat more convenient uninstall process
when using Flakes; put `uninstall = true` in your existing
configuration and then do a switch.
Also add simple uninstall test in CI test job.
