When nix-darwin has `nix.enable = false` (e.g., for Determinate Nix
users), accessing `config.nix.package` throws an error:
error: nix.package: accessed when `nix.enable` is off
This regression was introduced in commit a521eab when adding the
`home.uid` option. The code restructuring changed `inherit (config.nix)
package` to be evaluated unconditionally, whereas PR #6383 had
previously ensured this worked correctly.
The fix wraps the package assignment in `mkIf config.nix.enable` to
only access `config.nix.package` when nix management is enabled in the
host OS configuration.
Fixes: #8303
`uid` isn't guaranteed to be defined, have fallback logic in place to
account for that. Even if we require it eventually, we can't show a
proper assertion/warning without being able to eval.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Add a home.uid option similar to home.username. When set, the
activation script verifies the current UID matches the expected
value using the new checkUid function.
When using the NixOS or nix-darwin modules, home.uid is
auto-discovered from users.users.<name>.uid when that value
is set.
This is useful for constructing paths that depend on the user's
UID, such as /run/user/<uid> paths for gpg-agent sockets or
other user-specific runtime directories.
A first step towards refactoring the module.
Unfortunately the config is not consistent in using comma-separated
values or repeated keys for lists, since the user can always add commas
by themselves, we should default to repeated keys in the generator.
This includes the calendar/contacts prefix in the storage name as well
as the pair name to ensure that if the same name is used for contacts
and calendar then it is correctly referenced.
With swayidle one can configure two different kinds of hooks:
- Idle timeouts are executed after the session has been idle for a
specific amount of time.
- Events are executed when systemd notifies us that for example the
user session is locked or that the device is about to suspend.
While not obvious, there is a significant difference between how these
two kinds are configured: there can be several timeouts with separate
commands to be executed, but each event can only be specified once. If
an event is specified multiple times, then the last command wins.
This can be very easy to miss in swayidle's documentation. Furthermore,
because the config is a list of `{ event = "..."; command = "..."; }`
attrset, we double down on this confusion and make it seem like having
multiple handlers for an event was actually supported.
Fix this by converting from a list of "event" submodules to an attrset
where the key is the event name and the value is the command to be
executed. This makes it impossible to specify multiple commands for a
single event by accident.
If a user _does_ want to have multiple commands executed on any event
they can for example use `pkgs.writeShellScript` and manually chain the
commands in that script.
`lib` comes from the Nixpkgs used to instantiate Home Manager itself and
cannot change within the module fixpoint. However, `pkgs` is configurable
(via `nixpkgs.*` or `_module.args`) and may come from a different Nixpkgs
instance from the one providing `lib`.
Mismatches between Home Manager's release and the release of the `pkgs`
instance are more common and also more likely to cause subtle issues.
This change extends the release check to include `pkgs.lib.trivial.release`
so that such mismatches can be detected and reported.
You would encounter an eval error when a module (such as pimsync) would
try to access an attribute of `accounts.contacts.<name>.local`, since it
would default to `null`. The same problem was encountered in the
`accounts.calendar` module, and fixed in
2c157e22dc which has the same solution.
Closes#8258
Reported-by: redbeardymcgee
Automated update of the master maintainers list combining:
- Home Manager specific maintainers from modules/lib/maintainers.nix
- Nixpkgs maintainers referenced in Home Manager modules
**Added:** 1 maintainers
**Removed:** 0 maintainers
**Total:** 280 → 281 maintainers
**✅ Added:** arunoruto
Generated by: lib/python/generate-all-maintainers.py
home-manager's generated completions shadow built-in completion scripts.
fish actually has logic to deal with this when the path ends with
/generated_completions, so let's take advantage of it.
Link: 47c773300a/src/autoload.rs (L421-L424)
By default, dconf uses $XDG_CONFIG_HOME/dconf/user as the user database, but this can be changed by specifying user-db:<name> in a profile file and setting the DCONF_PROFILE environment variable to that profile. One may want to use different user databases for different DE/WMs to avoid collision.
Currently the module invokes dconf without touching DCONF_PROFILE, which means that 1) it is unable to configure multiple different user databases, and 2) the behavior of activation script will be affected by the DCONF_PROFILE environment variable when it is invoked, possibly leading to undesired results.
This PR adds a dconf.databases option, so that settings under dconf.databases.<name> will be written to $XDG_CONFIG_HOME/dconf/<name>. The old dconf.settings option is left as-is to avoid breaking compatibility.
This is a fix for PR #7108 that forcibly enables xdg-desktop-autostart
units, whether or not `config.xdg.autostart` is enabled.
Partially fixes#7708, there is still a risk for conflict if
`xdg.autostart` and `services.picom` are enabled.
