Allow modules to define systemd services on macOS. It won't actually
have any effect, but it would allow modules to define both systemd
services and launchd agents without boilerplate conditionals.
As a consequence of this change, each module would have to check for
compatibility with the OS target instead.
Internally we already managed them per-profile but exposed a global
option to maintain backwards compatibility. The benefit to having
per-profile extensions is quite large though, so it is time to switch.
Users of the global extensions option will get an error message that
indicates how to edit their configuration to work again.
Firefox internally only supports bool, int, and string types for
preferences, but often stores objects, arrays and floats as strings.
This change makes it nicer to specify those type of preferences in
Nix, and it also makes it possible to merge objects & arrays across
multiple modules.
This reflects a systemd service sample file change made in borgmatic
1.7.6, commit 2e9f70d49647d47fb4ca05f428c592b0e4319544:
When backing up a machine with a monitor using logind to control
idle timeout and things like DPMS, borgmatic can block the screen
from turning on/off with systemd-inhibit. This is because by
default systemd-inhibit will block
"idle:sleep:shutdown". Borgmatic does not need to care about idle,
only about suspend and shutdown. So, add an explicit `--what` flag
for what borgmatic should inhibit.
For more information see systemd-inhibit(1).
Some JVMs pass through `home` as a derivation rather than as a string, as `openjdk` does. Since the module option for session variables expects a string, this is a type error. I suspect that this incorrect, and have changed the assignment here to coerce the `cfg.package.home` attribute to a string to be safe.
After discussing with @NobbZ, we have decided it is best to mitigate this problem in HM rather than to make potentially breaking changes to Nixpkgs.
Please do mention if you think we ought to propose a change to Nixpkgs instead.
Allow setting the application package and storePath used by the
config. Since the `programs.password-store` Home Manager module sets
config values via global environment variables, the default behavior
of the module should continue to behave as before for the user.
Additionally,
- Adds a few tests.
- Use "escapeShellArg" function call to the path parameter call to
ensure paths with spaces work.
- Allow not setting storePath, which will cause `pass_secret_service`
to default to using `~/.password-store`.
- If `pass-secret-service` is enabled, set its store path to default
to the one defined in our password-store environment settings.
- Add myself (houstdav000) as maintainer.
Fish shell doesn't require arguments to `eval` to be double quoted
like in a bash shell. At the moment doing so gives us the following
error:
~/.config/fish/config.fish (line 12): $(...) is not supported. In fish, please use '(/nix/store/8asq…)'.
eval "$(/nix/store/8asqgnhs89wzyjvs8p1n5hvxn7lkn9wa-opam-2.1.3/bin/opam env --shell=fish)"
^
from sourcing file ~/.config/fish/config.fish
called during startup
source: Error while reading file “/home/user/.config/fish/config.fish”
This commit fixes the above error.
The default value of `programs.ncmpcpp.mpdMusicDir` is taken from
`services.mpd.musicDirectory` if the mpd module is enabled, which has
type `either path str`. `programs.ncmpcpp.mpdMusicDir` did not accept
`str` values, though, so an error was raised when the default value was
used and `services.mpd.musicDirectory` was set to a value of type `str`.
This commit changes the type of `programs.ncmpcpp.mpdMusicDir` to also
accept `str` to reflect the type of `services.mpd.musicDirectory`.
Fixes#3560
* home-environment: use `lazyAttrsOf` for `home.sessionVariables`
`attrs` has unreasonable merge semantics and is deprecated. `attrsOf`
doesn't support variables depending on each other as is recommended in
the option's description.
* home-environment: restrict `sessionVariables` type
The consumer is `toString`, but we don't want to accept e.g. lists.
Assigning to `programs.neovim.extraLuaPackages` a function taking a lua package set as input
and returning a list of packages, as described in the documentation,
threw an error because the rest of the code assumed that the value was always a plain list.
Using `lib.types.coercedTo`, we can accept such functions, as per the documentation,
as well as plain lists, which we then convert to a function ignoring its input argument.
We print a warning when a plain list is assigned, since the function
form is preferred, as it ensures that the right lua package set is used.
For the lua packages, we also get the lua package set from the
finalPackage, to make sure that we are always using the same package set
as the actual unwrapped neovim package being built.
For `programs.neovim.extraPythonPackages` I did the same.
I updated the test case so that we test both ways of setting these options.
