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
This has no effect if the user does not have any aliases defined for
any accounts.
This will also only add `--my-address=` to only accounts that are
enabled to be tracked by mu.
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.
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
This option provides a more convenient way to overlay dummy packages.
It also adds a function `config.lib.test.mkStubPackage` that can,
e.g., be used for `package` options.
Bottom is a cross-platform graphical process/system monitor with a
customizable interface and a multitude of features.
Two unit tests were added validate the module behavior for an empty
configuration and the example configuration.
Fnott is a keyboard driven and lightweight Wayland notification daemon
for wlroots-based compositors.
There are four unit test to validate behavior for an empty
configuration, the default configuration, global properties and
systemd service file generation.
* bspwm: various improvements
- fixes shell escaping issues and general style issues
- allow reloading the config on-the-fly by exposing bspwmrc to the user
* bspwm: add configuration test
