This brings a few advantages:
- Use of float instead of strings to represent float values,
- Use of structure settings, and
- Better type checking for some settings
Also add thiagokokada as codeowner of picom.
mujmap is a tool that synchronizes mail between a mail server and
notmuch via JMAP. It's very similar to lieer, so I heavily based the
implementation of the notmuch module on lieer's. I did not include an
equivalent to lieer's periodic synchronization service, however,
because I plan to soon introduce a daemon mode to mujmap.
https://github.com/elizagamedev/mujmap
This is adapted from the `services.mopidy` NixOS module. The
difference is the setting can be configured with Nix language, taking
advantage of generators from nixpkgs. The module is also suited more
for user-specific configuration, removing the `extraConfigFiles` and
`dataDir` option.
* home.pointerCursor: init
The current architecture for cursor configurations is composed of individual
options for different backends. For example, X specific settings are managed under
`xsession.pointerCursor` and gtk specific settings are managed under `gtk.cursorTheme`.
While this architecture is modular, it causes duplication of similar structures for
each component. In theory, this provides flexibility because the components are independent
of each other which can be arranged in arbitrary ways to achieve the desired result.
However in practice, users wish to have one cursor theme applied to their entire system
The duplication of options correspond to duplication of settings on the user side and it
becomes a burden to keep track of all necessary settings.
This commit is an attempt to unify cursor configurations for different window systems and
GUI toolkits based on https://github.com/nix-community/home-manager/pull/2481#issuecomment-978917480.
`home.pointerCursor` is introduced as the interface for all cursor configurations.
It contain all options relevant to cursor themes with eneral options delcared under `home.pointerCursor.*`
and backend specific options declared under `home.pointerCursor.<backend>.*`. By default, a backend
independent configuration is generated. Backend specific configurations can be toggled via the
`home.pointerCursor.<backend>.enable` option for each backend. This was decided over using a
list of enums because it allows easy access to the state of the backend. Note generating different
cursor configurations for different backends is still possible by defining only `home.pointerCursor`
and managing the respective options manually.
* xcursor: migrate options to home.pointerCursor
- Removed `xession.pointerCursor` as x11 cursor configurations are now handled in `home.pointerCursor.x11`.
- Updated `meta.maintainer` field in `home.pointerCursor` and CODEOWNERS.
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
The idea of this file is to make it easier to run tests. It will ensure
that the tests are running with the correct NIX_PATH (pointing it to
e.g.: unstable), and also allowing it to run either one or all tests.
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.
* pulseeffects: change default example
pulseeffects-pw is now an alias to easyeffects, and the `pulseeffects` binary
that this module references is no longer in that package.
* easyeffects: add module
The easyeffects service is the PipeWire equivalent of the pulseeffects
service.
* 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
- Add support for showing bold as bright colors
- Add support to configure the background transparency
- Fix the scrollOnOutput, it was not being dumped to the config
- Add tests!
- Add myself as maintainer
`rbw` is a stand-alone Bitwarden client, which makes use of a daemon to
cache your password and manage state.
Its configuration can be managed by `home-manager` or not, leaving the
user free to configure it through `rbw config`.
* xdg-desktop-entries: add module
rebase
* xdg-desktop-entries: adapt to changes in makeDesktopItem
This package depends on the makeDesktopItem function in nixpkgs, which recently changed its syntax:
https://github.com/NixOS/nixpkgs/pull/91790
This commit makes the module compatible with the new syntax.
It also exposes the fileValidation option in makeDesktopItem.
Co-authored-by: cwyc <cwyc@users.noreply.github.com>
Co-authored-by: --get <--show>
* htop: add some missing meters
* htop: replace individual options with 'settings'
Deprecate all options and introduce `settings` for setting htop configuration
values in Nix configuration.
Use `lib.htop` to provide `fields` and `modes` for easy access to htop's integer
configuration. And `leftMeters` and `rightMeters` functions for building the
separate `*_meters` and `*_meter_modes` attributes.
* htop: add release-notes 21.05 entry
* htop: improve deprecation warnings
Move default configuration into `settings` and make deprecated options default
to `null`. Print deprecation warnings for any option that is non-null --
i.e. only show warnings for explicitly specified deprecated options.
* htop: make self code owner of module
* release notes: fix invalid programs.htop xref
Foot is a fast terminal emulator for Wayland. It can optionally be run
in a client-server configuration.
There are three unit tests to handle an empty configuration, the
default configuration, and systemd service file generation.
There is a need to manage XDG Base Directory system directory
environment variables in Home Manager modules. There is an existing
mechanism in `targets.genericLinux.extraXdgDataDirs', but this does not
apply to NixOS systems.
Furthermore, it is important that `XDG_CONFIG_DIRS' and `XDG_DATA_DIRS'
are set in both login shells (to support getty and SSH sessions) as well
as the systemd user manager (to propagate them to user services and
desktop environments).
The first need is addressed by adding the `xdg.systemDirs' module, which
configures lists of directory names for both `config' and `data'
directories. These are then set in
`$XDG_CONFIG_DIR/environment.d/10-home-manager.conf' and picked up by
the systemd user manager.
To make these, and other variables set in
`systemd.user.sessionVariables', available in login shells, an
additional step is added to `etc/profile.d/hm-session-vars.sh' which
exports the result of
`user-environment-generators/30-systemd-environment-d-generator' which
is shipped with systemd. The effect of this generator is to print
variables set on the systemd user manager such that shells can import
these into their environment.
`nix-index` is a tool to quickly locate the package providing a certain
file in `nixpkgs`. It indexes built derivations found in binary caches.
This module adds the shell integration for its `command-not-found`
script for interactive shells.
* ncspot: add module
ncspot is a ncurses Spotify client written in Rust using librespot.
* news: fix bad github ui merge
Co-authored-by: Nicolas Berbiche <nicolas@normie.dev>
* i3, sway: extract border functionality to common function
Converted the i3 module to use default_border and
default_floating_border and extracted that functionality out to be
shared between the i3 and sway modules.
* i3: add sumnerevans as maintainer
Nowadays services.{redshift,gammastep} modules are really similar. They
should, since Gammastep is a fork of Redshift with the main objective is
to support Wayland.
So instead of trying to maintain two separate modules, this commit unify
the options in lib/options.nix file, making the implementation of the
module itself ends up being really simple (just calling the common
options with the necessary parameters to differentiate between them).
* rofi: migrate to rasi configuration format
The Xresources configuration format is deprecated in Rofi. For example,
using Rofi from unstable (1.6.1 as of now) you get the following
warnings when starting the application:
```
(process:9272): Rofi-WARNING **: 01:38:48.596: The old Xresources based configuration format is deprecated.
(process:9272): Rofi-WARNING **: 01:38:48.596: Please upgrade: rofi -upgrade-config.
``````
So this commit migrates it for its new configuration format, called rasi
instead.
This new implementation uses attrsets manipulation instead of using
strings, making the code clearer and also fixing some bugs found during
the way. To make sure everything is right, I also created some tests.
If someone wants to validate if the generated config is correct, just
run in terminal:
```
$ rofi -dump-config
```
And rofi will dump the current configuration file, including all
unsetted options.
* docs: document programs.rofi.extraConfig changes
* rofi: add thiagokokada as maintainer
* rofi: add toRasi function
This test requires copying the Home Manager checkout to the Nix store,
which seems to require too much memory for the CI jobs. Instead simply
run the format script directly.
* mbsync: option for configuring a channel
A channel is a relationship between 2 directories/boxes/mailboxes
between the local machine (slave) and the remote mail server (master).
Each channel must be given at least:
* an account-unique name
* a pattern for which mailboxes to sync from master
* a pattern for what directory where that mail ends up on the
slave
Additional options can be added later.
* mbsync: option for configuring a group
A group is a grouping of channels together, so that many channels with
very different names can be handled as a single entity.
Groups are unique in mbsync because they will shadow channels that
have the same name on the command-line.
* mbsync: create groups configuration attribute
This is the end of the configuration that the end-user will use.
They will specify an attribute set that contains the name for the
group, so they can say
`accounts.email.accounts.<aname>.groups.<gname>` to access the
configuration for the group with the name `<gname>`.
* mbsync: write function to generate group-channel blocks
This function takes in a set of groups, and their consituent
channels and writes the appropriate .mbsyncrc block. The block is as
shown below:
Group groupName1
Channel channelName1
Channel channelName2
Group groupName2
Channel channelName3
Each group must have a unique name, no matter which account it is
declared under. The same holds true for channels. However, if there is
a group that shares the same name as the channel, the channel will
effectively be "shadowed" by the group, and mbsync will default to
working with the group in that case.
* mbsync: write function to generate channel configuration blocks
This function takes in a set of groups, which includes their
consituent channels and writes the appropriate .mbsyncrc block for the
channel. The block that is generated is shown below:
Channel groupName1-channelName1
Master :<accountName>-remote:<master-pattern>
Slave :<accountName>-local:<slave-pattern>
Channel groupName2-channelName2
Master :<accountName>-remote:<master-pattern>
Slave :<accountName>-local:<slave-pattern>
Each group must have a unique name, no matter which account it is
declared under. The same holds true for channels.
Using channels with the patterns set up this way allows one to specify
which maildir directories are to be synchronized FROM the master TO
the slave. In addition, it allows for these maildirs to be remapped,
between the master server and the local slave.
This is critical, because Gmail has a strange way of storing its mail
that makes using mbsync, mu, and mu4e more difficult.
There are additional channel parameters that are already present in
this codebase from the previous use of group-channel configuration,
which will be reused.
* mbsync: set the submodule's names field according to parameter
This is the same method as is used in creating an email account, named
`<name>` under `accounts.email.accounts.<name>`. This allows the user
to specify groups and channels, in a list-like format, but still gets
the "namespacing" to more easily handle the options available in each
of these locations.
* mbsync: provide examples of master/slave patterns for channels
* mbsync: create nested-let function to generate channel pattern
This pattern is required to either NOT be present, which means the
master pattern is used to match, or it has a list of patterns to use
beneath the master maildir to match against.
This function checks to ensure that if patterns is not empty, ONLY
then is the `Pattern` keyword printed. Otherwise, there are many, many
problems.
If there IS a list of patterns, then we use proper escaping methods to
ensure that the exact string is constructed.
* mbsync: per-account groups can have additional patterns
Gave the
`accounts.email.accounts.<name>.mbsync.groups.<gname>.channel.<cname>`
set a `patterns` option, which will allow for greater customization
and filtering of the master maildir to sync to the slave maildir.
* mbsync: add extraConfig option for easier-to-format options
These are options that can be handled by the `genSection` function in
the `genAccountFunction`, so they are left to the user to decide.
Most of these are made on a global basis anyways.
* mbsync: remove unneeded extraConfig.channel
This was originally placed here, seemingly, just to get this module
working. However, this field is actually more confusing now that a
separate per-channel configuration option for extra configurations has
been made available.
* mbsync: correct and improve comment in masterPattern description
* mbsync: switch channel/group generation to new functions
Changing this out is what moves us from the old system to the new one.
Instead of having a single channel manage a whole mailbox, we can now
specify an attribute set of groups that should correspond to an email
account.
Each of these groups contains an attribute set of channels that make
it up, and are grouped together for synchronization. In addition, each
of these channels can have additional IMAP4 parameters attached to
them to further refine synchronization.
Lastly, each of the channels is grouped together under the Group
section, ensuring that the channels' mailboxes synchronize as they
have been specified.
* mbsync: only generate group/channel configuration if channels present
Typically, when a group is specified, channels will be specified as
well. However, if due to error or mistake, the user forgets to specify
ANY channels for a group, we should not generate that group's
information.
This means that no channels are specified (which maps the remote
master to local slave). In addition, the `Group <gName>` block (which
brings the separate channels together) is also not generated.
Another thing to consider is that a user might specify a group and a
channel, but perform no additional configuration of the channel.
In a configuration, this would be realized by
`accounts.email.accounts.<aName>.mbsync.groups.<gName>.channels.<cName>;`
This creates the channel with the name `<cName>` and the
`masterPattern`, `slavePattern`, and `patterns` fields use their defaults.
By definitions set within mbsync, these defaults actually specify that
the remote master's `INBOX` mail directory is synchronized to the
local slave's `INBOX` directory.
So, if there is a channel that has no fields specified, then we DO
want to generate its configuration. But if there is a group that has
no channels, then we do NOT generate it.
* mbsync: acc comment explaining why groups attr set is never empty
* Revert "mbsync: remove unneeded extraConfig.channel"
This reverts commit 941c4771ca.
To support backwards compatibility, I need to leave this field/option
in the module, even if it will likely be more confusing to do it this way.
* mbsync: channel compatibility with previous iteration of mbsync
The previous version of mbsync used a single channel for an entire
account. This leads to issues when trying to change the mailbox
hierarchy on the local machine. The problem with this is that some
email providers (Gmail, among others) use a slightly different maildir
hierarchy, where the standard mailboxes (Inbox, Drafts, Trash, etc.)
are stored inside another directory (`[Gmail]/` in the case of Gmail).
This new version allows the user to specify any number of groups with
any number of channels within to reorder their mail however they wish.
However, to maintain backwards compatibility, I moved the original
channel-generating code to a function that will run ONLY when
there are no groups specified for THIS account.
* Revert "mbsync: channel compatibility with previous iteration of mbsync"
This reverts commit b1a241ff9f.
This function is in the wrong location and this was wrongly committed.
* mbsync: function for backwards compatibility with previous mbsync
NOTE THAT THIS IS THE CORRECT COMMIT FOR THIS CHUNK OF CODE!!
The previous version of mbsync used a single channel for an entire
account. This leads to issues when trying to change the mailbox
hierarchy on the local machine. The problem with this is that some
email providers (Gmail, among others) use a slightly different maildir
hierarchy, where the standard mailboxes (Inbox, Drafts, Trash, etc.)
are stored inside another directory (`[Gmail]/` in the case of Gmail).
This new version allows the user to specify any number of groups with
any number of channels within to reorder their mail however they wish.
However, to maintain backwards compatibility, I moved the original
channel-generating code to a function that will run ONLY when
there are no groups specified for THIS account.
* mbsync: function to choose which style of group/channels to generate
This is a simple if-check. If the old style is used, then this
account's mbsync.groups attribute set is empty. If that is the case,
then the old-style single-channel per account is used.
If that is NOT the case, then the new style is used in preference of
the old. This means that ALL channel code that would be generated by
the old version is replaced by the new one.
* mbsync: switch per-account config generation to check channels
* mbsync: program-wide groups if no account-specific groups
At the end, we have to choose whether or not to generate the old style
of having program-wide groups to specify things, where the boxes on
the channel underneath the group specifies which mailboxes to sync.
Here, we only generate the old style of group IF there is ANY account
that does NOT have the new `accounts.mbsync.groups` defined. At that
point, it is up to the user to ensure that the accounts in
`programs.mbsync.groups.{}` align with the name chosen for the
account, as I have made no attempt to change this old code.
However, if ALL accounts have their `mbsync.groups` defined, even if
each of the groups has a single empty channel, it will generate the
groups in the new style.
* mbsync: ensure \n after hm-generated comment
This was a multi-part fix. First, the `# Generated by Home Manager.`
comment has been reworked to ensure that it will ALWAYS have a
newline, even if the program-wide extraConfiguration is empty.
Next, we switched to placing 2 newlines between every account, to
provide further visual distinction between each account, which can
have multiple channels and multiple groups defined at the same time.
Lastly, the groupsConfig was slightly reworked, so that both the old
and new version can be used, but the new one will take precedence.
Because of this, groupsConfig is now a list of strings, which will
have single newlines inserted between each element.
But if the old style is NOT used, then the groupsConfig list
contains one element, an empty string. A single element has nothing
added as a separator, and an empty string produces no output.
* mbsync: only generate new group/channels if channels present
Here, the problem was if the user created a group for an account, but
did not also include a set of channels. If no channels have been
specified, then the group should NOT have its group-channel mapping generated.
I also corrected and improved the comment regarding
`genGroupChannelString`'s function and intended behavior.
* mbsync: channel patterns generate their own newlines
This means that when a channel has extra `patterns` defined for it, it
will generate those, and a single newline will be appended to the end
of that newly constructed string.
The moving of the newline character is slightly important because
otherwise, every account would receive an extra newline after every
channel, leading to 2 newlines after every channel.
* mbsync: place newline between each channel in a group
* mbsync: ensure old group/channel has proper spacing
This ensures that if the old style of generating program-wide groups
that there is the proper spacing before the group and in between each
line within the group.
* mbsync: ensure no empty channels present
If the user specifies a group correctly, they must still specify an
attribute set of channels. However, if they do not, then we need to
ensure that a group with no channels does NOT have any channel
configurations generated for it.
If there is a channel string generated for a channel that is empty,
then the `mapAttrsToList` returns a singleton list that contains just
the empty string. Thus, we can filter out all those results, to ensure
that no empty channels are generated.
It is important to keep in mind the difference between an empty
channel and a channel that has received no configuration, but is
named.
* A named channel is technically configured to have a name.
While the `masterPattern`, `slavePattern`, and `patterns`
field have NOT been populated, mbsync assumes that if
master/slave-Pattern are empty that means match against
`INBOX`.
If `patterns` is empty, no patterns are printed.
* An empty channel set is a set that has no channels within
it, but `mbsync.groups.<gName>.channels` is defined.
* mbsync: filter empty groups and correct newlines
First thing, someone can specify that a group is empty. If this is
done, technically a group with channels would be generated at the end.
However, because they were empty and did not exist, whitespacing would
be generated, leading to a usable, but mangled config file.
The `filter` solves this problem by removing empty strings (which are
generated by groups that are empty) from the output strings to place
in the file.
Lastly, because the whitespacing was fixed elsewhere in the file, the
crazy double-newline at the end was changed to a single newline.
However, the double newline within the `concatStringsSep` is still
required, because the list that is being concatenated together is a
list of channel configurations. Each element corresponds to one of the
groups specified, whose contents are the channels specified within.
The double newline is needed because each string element is lacking a
trailing newline, because `concatStringsSep` does not add the
separator to the end of the last element in the list. So, the last
channel to be configured will not have that newline appended when the
channel-configuration list is created, thus, 2 are inserted here.
* mbsync: update test input to use per-account channels
* mbsync: comment how old/new style collision handled
This is left in the test input for now, because I think it is useful
to see why certain things are happening the way they are.
* mbsync: update test output pattern
The test output should now have the correct configuration according to
the way I have specified it in the input file.
* mbsync: use format script on new code
* mbsync: add KarlJoad as maintainer
Co-authored-by: Nick Hu <me@nickhu.co.uk>
