Nix permits user level configurations through ~/.config/nix/nix.conf that allow
customization of system-wide settings and behavior. This is beneficial in chroot
environments and for per-user configurations. System level Nix configurations in the
form of /etc/nix/nix.conf can be specified declaratively via the NixOS nix module but as
of currently no counter part exists in home-manager.
This PR is a port of the RFC42 implementation for the NixOS nix module[1]
to home-manager. Non-applicable options have been excluded and the config generation
backends have been tweaked to the backends offered by home-manager. A notable change
from the NixOS module is a mandatory option to specify the Nix binary corresponding
to the version "nix.conf" should be generated against. This is necessary because
the validation phase is dependent on the `nix show-config` subcommand on the host platform.
While it is possible to avoid validation entirely, the lack of type checking was deemed too significant.
In NixOs, the version information can be retrieved from the `package` option itself which
declares the Nix binary system-wide. However in home-manager, there is no pure way to
detect the system Nix version and what state version the "nix.conf" should be generated
against. Thus an option is used to overcome this limitation by forcing the user to
specify the Nix package. Note this interaction can still be automated by forwarding
the system-wide Nix package to the home-manager module if needed.
Three unit tests were added to test the module behavior for the empty settings, the example
settings and the example registry configurations respectively.
[1] - NixOS/nixpkgs#139075
Note, the pubs configuration file uses ConfigObj syntax, which is
similar to the INI files syntax but with extra functionalities like
nested sections. This prevents it from using Nix's INI format
generator. Here is an example of pubs configuration that cannot be
generated using Nix's INI format generator:
[plugins]
[[git]]
manual=False
For this reason, we opted for a stringly-typed configuration since the
use of a structured `settings` option would require a custom parser.
Watson is a CLI for tracking your time.
Two unit tests were added to validate the module behavior for an empty
configuration and the example configuration.
Swayidle is an idle management daemon for Wayland. This modules adds support for
running swayidle as a SystemD user unit and makes it configurable through
home-manager.
Swaynag is a replacement of i3-nag for sway. Swaynag is embedded in
Sway's build process albeit it is not an integral part of Sway,
therefore it has been added under `wayland.windowManager.sway` instead
of `programs`. It can be moved at a later time if necessary.
Two unit tests were added validate the module behavior for an empty
configuration and the example configuration.
This commit introduces the `nixpkgs-disabled` module, that is
basically a mock of `nixpkgs` module where any value different from
`null` will cause an assertion error.
This is to help debugging cases where `home-manager.useGlobalPkgs` is
set to `true` and `nixpkgs.*` options are being used.
Nowadays this returns the following error:
```
error: The option `home-manager.users.<user>.nixpkgs` does not exist.
```
This will change too:
```
error: `nixpkgs` options are disabled when `home-manager.useGlobalPkgs` is enabled.
```
That will direct the user to the correct solution (either removing
`nixpkgs` or disable `home-manager.useGlobalPkgs`).
nnn is a terminal file manager.
It is configured mostly using environment variables, so the way I
found it to avoid needing to write either shell specific code or
using `home.sessionVariables` (that would need to make the user
relogin at every configuration change) is to wrap the program using
`wrapProgram`.
This commit adds a module for configuring atuin, a replacement shell
history program.
The module adds options for generating atuin's `config.toml` from Nix,
and options to enable atuin's integration for bash and zsh
(which will rebind history keys to open the atuin history).
* screen-locker: Make xautolock optional, reorganize options
xautolock isn't really needed to trigger xss-lock on the basis of time
since the built-in screensaver functionality of X serves as one of the
event sources for xss-lock. Keeping it around and defaulting to
"enabled" to avoid unexpected breakage.
Also shuffled around the options to submodules for xss-lock and
xautolock to get rid of prefixes in option names and to make
enableDetectSleep a bit clearer.
* screen-locker: update maintainership
* tests/screen-locker: Stub i3lock and xss-lock
* screen-locker: add package options for xss-lock and xautolock
