We only need the Home Manager path variables when performing a few
operations, so only set the variables for those operations.
This avoids problems on fresh installations, where no profile
directory exists.
Fixes#4403
(cherry picked from commit ae896c810f)
Occasionally, swayidle crashes with a failure to connect to the
Wayland session. Ideally, swayidle should automatically restart
instead of leaving the system in a vulnerable state.
(cherry picked from commit 50e582b9f9)
Setting `outputSpecified` prevents `getOutput` from descending into
outputs, which don't have an overridden `outPath`.
Additionally, use `__spliced` to permit derivations to use the dummy as
an input.
(cherry picked from commit 221056c59f)
Nix 2.17 changed the format of the `nix profile list` output. This
commit adds support for parsing the new JSON profile list format.
Fixes#4298
(cherry picked from commit c3ab5ea047)
We can't test for the whole contents of the config file because that is
out of our control and may change unexpectedly. Only check for the
settings we know should be set.
In 176e455 the order between the action of `-I` parameters getting
added to `EXTRA_NIX_PATH` and the action of a static path getting
added to `EXTRA_NIX_PATH` was reversed, also reversing the order of
`-I` parameters and the static `-I home-manager=...` leading to the
static `-I home-manager=...` to always come before any of the `-I`
parameters to later calls to Nix commands.
This made it impossible to override the static Home Manager path when
calling the home-manager tool with `-I home-manager=...`. This was
previously possible.
(cherry picked from commit edf9cf6523)
* tests: `--show-trace` in CI (#4070)
(cherry picked from commit f889ec0ec3)
* tests/stubs: inherit default versions from pkgs (#4069)
* tests/stubs: inherit default versions from pkgs
* tests/browserpass: temporarily disable on darwin
The package currently fails to evaluate on darwin due to a nixpkgs
problem: https://github.com/NixOS/nixpkgs/pull/236258#issuecomment-1583450593
(cherry picked from commit 69bdd6de50)
* Espanso: Fix broken module to be compatible with Espanso version 2.x (#4066)
* Fix espanso module to work with 2.x version
* espanso: fix espanso module
This module is currently broken. It does not create `config` and `match` folders which are required by espanso 2.x version.
This PR fixed this issue and support creating multiple files under `config` and
`match` folder.
* Espanso: fix espanso module
This module is currently broken. It does not create `config` and `match` folders which are required by espanso 2.x version.
This PR fixed this issue and support creating multiple files under `config` and `match` folder.
Add descriptions
* Add versionAtLeast and mkRemovedOptionModule
* Correct maintainers list
* remove config key from example
* format basic-configuration.nix
* Update modules/services/espanso.nix
Co-authored-by: Naïm Favier <n@monade.li>
* fix maintainers list
---------
Co-authored-by: Naïm Favier <n@monade.li>
(cherry picked from commit 1e5d741ea3)
---------
Co-authored-by: Li Yang <71299093+liyangau@users.noreply.github.com>
This is backwards compatible and allows for more flexibility(eg.
allows for defining custom waybar modules in separate nixos modules,
before merging them together)
Co-authored-by: mae <git@badat.dev>
Make use of the recently added nullable `mkPackageOption` feature
to disable installing an SSH client by default: most people should use
the client provided by their system.
The generation activation script should be run by the user specified
in `home.username` and `home.homeDirectory`. If some other user runs
the activation script, then files may end up in the wrong place or
with the wrong owner.
This commits adds a check early in the activation script that verifies
that the running user match the user in the configuration.
Fixes#4019
Before this commit, running the hasFlakeSupport function causes an
error message
error: experimental Nix feature 'nix-command' is disabled; use
'--extra-experimental-features nix-command' to override
when the Nix installation does not support the nix tool. The error
message should not be visible to the user since its just part of the
Flake support check.
* PR_TEMPLATE: Note nix3 test method in checklist
Allows for running with the `nixpkgs` from the lock file, as well as
using a more familiar interface for users of the experimental CLI, which
would've avoided me opening #3971.
Also updates the corresponding note in `docs/contributing.adoc` to have
the correct invocation path.
* PR_TEMPLATE: `the experimental CLI` -> `Flakes`
* zellij: adds options to integrate with zsh, bash and fish shells
* zellij: add tests for shell integration options
* zellij: eval setup auto start for fish integration
* zellij: use interactiveShellInit for fish integration
* zellij: fixes format issues
* zellij: enable shell integrations by default
* zellij: compresses shell integration test cases
* zellij: removes the disabled shell integration tests
* zellij: formats tests
* pass-secret-service: Add dbus file, assert
Add the dbus service file in the package folder to XDG_DATA_HOME, as
well as adding an assertion to ensure both it and `gnome-keyring` aren't
enabled at the same time.
* pass-secret-service: Add self to CODEOWNERS
* pass-secret-service: Call out conflicting module(s)
* pass-secret-service: Revert `storePath` change
Signed-off-by: Cynthia Fox <cyntheticfox@gh0st.sh>
* pass-secret-service: Add password-store module default changes info
* pass-secret-service: Fix default info, modularize conflict checks
Signed-off-by: Cynthia Fox <cyntheticfox@gh0st.sh>
* Revert "pass-secret-service: Fix default info, modularize conflict checks"
This reverts commit 851df4fe49.
* pass-secret-service: Fix default info
Signed-off-by: Cynthia Fox <cyntheticfox@gh0st.sh>
* pass-secret-service: Indent `storePath` description
---------
Signed-off-by: Cynthia Fox <cyntheticfox@gh0st.sh>
* himalaya: add soywod to maintainers
* himalaya: make the config safer
Also added two services and more tests.
* himalaya: fix doc + typos
* himalaya: use freeform
* himalaya: run ./format
* himalaya: make use of mkPackageOption
It's pretty common to need multiple bindings to
history-substring-search, since different terminals will send different
keys for up/down.
This does not break back-compatibility, and introduces a new test
The current zplug nixpkgs puts everything under `$out/`. It pollutes the nix
profile dir.
This is a breaking change. It depends on an change of the output path in the
nixpkgs zplug package.
This reverts commit 6f9781b1b0 to fix
errors of `nix flake check` and `nix flake show`.
The `devShells` attribute is expected to be an attrset of derivations,
not nested attrsets.
Virtual mailboxes (described by Notmuch queries) can now configured for each account in NeoMutt.
Plus, it is possible to disable Notmuch section for a specific account.
Without this, even if you configure a preference for Electron apps to
use Ozone by setting `NIXOS_OZONE_WL=1`, GUI apps launched through
systemd user services use XWayland, since the variable is not set in
their environment.
This fixes that issue by importing it, like we do other variables.
The previous implementation tried to rename the tag named "default" to
the first tag in `cfg.tags`. This was a wrong approach because if a
tag with the same name already existed, the renaming failed and the
default tag would continue to exist.
The looking up of the default tag also contained a bug because it
should have used `by-name` in the path.
Before this change, the default config provided by this module wrote
an empty file to `$HOME/.config/avizo/config.ini`, which caused a
bunch of errors, as Avizo tries to read a 'group' from the ini file,
which fails.
This commit also adds associated test cases.
PR #3871
The added extraConfig option allowes users to insert custom text at
the end of the generated profile `user.js` file. This allows the users
to import templates as part of their configuration.
The link to the Nix RFC 42 is invalid. Replace this with a valid link to the
upstream NixOS/rfcs repo, pinning it to the commit that introduced the RFC.
The Nix profiles path may not exist right after installing Nix. In
that case, it is created on demand by the Nix CLI tools. However, Home
Manager assumes it exists and fails if it doesn't.
This change makes sure to trigger the creation of the Nix profiles
path before attempting to access it.
If the user runs a recent Nix version that places per-user profiles in
`$XDG_STATE_DIR/nix/profiles`, then migrate the home-manager profile
there.
Also clean up `setupVars` a bit.
While technically dconf on darwin could work, our activation step
requires dbus, which only *lightly* supports Darwin in general, and not
at all in the way it's packaged in nixpkgs. Because of this, we just
disable dconf for darwin hosts by default.
In the future, if someone gets dbus working, this _could_ be re-enabled,
unclear whether there's actual value in it though.
link the packpath in expected folder so that even unwrapped neovim can pick home-manager's plugins.
I sometimes need to run neovim not wrapped/configured by nix (when
developing neovim or when other projects bring their own neovim in
PATH). Currently they dont find plugins installed by home-manager in the
cases where packpath is not set to the generated nix packpath directory.
With this change, neovim can discover HM-installed plugins by itself.
Some of the email providers (like GMail and Fastmail) save Sent messages
automatically, so make the folders optional in the configuration.
Make Drafts folder optional as well, to allow it to be configured
manually in the extraConf with location outside of the maildir.
* i3status-rust: update it to handle 0.30.x releases
0.30.0 is a major release that brings many breaking changes to the
configuration file. See:
https://github.com/greshake/i3status-rust/blob/master/NEWS.md#i3status-rust-0300
The only one that actually affects the module though is the change in
how the theme/icons are defined. Other changes are mostly on how to
specify formatting/blocks, and since we just generate the TOML as-is, it
needs changes in the user side.
So most changes in this commit are documentation updates, having
up-to-date examples from things that changed, e.g.: the new `click`
attribute that now can be applied to any block.
* i3status-rust: only use new format if i3status-rust >= 0.30.0
* news: document the i3status-rust changes
* i3status-rust: add thiagokokada as maintainer
The `XCURSOR_*` environment variables specified in libxcursor
are used by many applications and libraries to load and configure
cursor settings. Setting these variables is a no-op if ignored but
is useful as a fallback when other sources of configuration are
unreliable.
This commit sets some commonly used `XCURSOR_*` environment variables
(i.e XCURSOR_THEME, XCURSOR_SIZE) by default when `home.pointerCursor`
is enabled.
The init command is essentially the old install script but integrated
into the home-manager tool. This simplifies things slightly since we
can use the existing code infrastructure.
The init command is Nix flake aware in the sense that, if we detect
that the user's Nix setup supports flakes, then we also create an
initial `flake.nix` file.
Finally, we update the installation instructions for the Nix flakes
standalone setup to use the new init command.
Zsh completion update provided by Anund <anundm@gmail.com>.
This command adds the ability to specify lists of qutebrowser
commands as values for key bindings, which avoids the need for
concatenating commands with ` ;; `.
This changes the default configuration location for Home Manager
configurations from
$XDG_CONFIG_HOME/nixpkgs
to
$XDG_CONFIG_HOME/home-manager
The old location is still supported but using it will trigger a
warning message.
Fixes#3640
Added a generator for the KDL document language.
This is in order for home-manager to natively generate
the new config format for zellij, as described in nix-community#3364.
There is not a one to one mapping between KDL and nix types,
but attrset translation is heavily based on KDLs JSON-IN-KDL microsyntax.
The exception here is the `_args` and `_props` arguments, which lets you
specify arguments and properties as described in the spec.
See more here:
- https://kdl.dev/
- https://github.com/kdl-org/kdl/blob/main/SPEC.md
The generator also conforms to the interface from the nixpkgs manual:
https://nixos.org/manual/nixpkgs/stable/#sec-generators
Co-authored-by: Gaetan Lepage <gaetan@glepage.com>
Install home-manager via `nix run` rather than `nix-build` then running
the activation script out of the store manually.
Co-authored-by: Cédric Barreteau <cbarrete@users.noreply.github.com>
Specifically, if the global per-user profiles path do not exist and we
cannot create it during the activation, then place our profile in the
Home Manager data directory. We prefer to use the global location,
though, since it makes it visible to `nix-collect-garbage`.
This is intended to improve compatibility with Nix version 2.14 and
later, which no longer creates the per-user directories.
Also, use the Home Manager data directory to manage the gcroot for the
current generation. It does not have to sit in the global per-user
gcroots directory since it should never be eligible for GC.
If used inside the NixOS/nix-darwin module, we get conflicting definitions
of `name` inside the specialization: one is the user name coming from the
NixOS module definition and the other is `configuration`, the name of this
option. Thus we need to explicitly wire the former into the module arguments.
See discussion at https://github.com/nix-community/home-manager/issues/3716
* exa: add more options
* exa: use `escapeShellArgs`
* exa: don't hardcode executable path in aliases
Prevents aliases from going stale in open terminals when the system is updated.
* exa: use `command` for self-referential alias
Otherwise fish complains about the recursive call.
Drop the aliases from ion shell since it doesn't implement the POSIX
`command` built-in.
* exa: re-add ion aliases
* exa: drop `command`
Fish doesn't complain about recursion if `exa` isn't escaped.
---------
Co-authored-by: Naïm Favier <n@monade.li>
The `-X` prevents that screen is cleared when showing a diff that's
larger than my screen.
I.e. when running `git diff` and press `q`, the last thing I want to see
is the prompt with `git diff` and *not* the part of the diff I browsed,
to be clear
$ git diff
$ <cursor>
Considering that this is somewhat opinionated, I decided to build an
option which allows you to pass arbitrary commands to the less
invocation.
Xsession (and hence ~/.xsession) is executed in bash but does not set
SHELL to the full path to bash. In case the user's login shell is
something other than bash then SHELL is set to that shell. Keychain
inspects the SHELL variable to find out what shell it has to generate
code for, so in .xsession it generates code for the user's login shell
instead for bash.
This change forces SHELL to bash for keychain when invoked from
.xsession, the same way it's done when generating keychain's code for
bash integration.
Closes#3693
* vscode: add extensions.json file in extensions dir
This change generates an 'extensions.json` file the same way that
nixpkgs' vscode-with-extensions does, and makes sure it is placed in the
directory with the extensions.
* vscode: remove leftover trace
Co-authored-by: Naïm Favier <n@monade.li>
* vscode: fix adding extensions.json with mutable extension dir
Co-authored-by: Naïm Favier <n@monade.li>
* vscode: let vscode regenerate the mutable extensions.json
* Remove nixpkgs duplication; only apply on vscodes new enough to need it
* Use lib.versionAtLeast
Co-authored-by: Naïm Favier <n@monade.li>
* Format vscode.nix
---------
Co-authored-by: Naïm Favier <n@monade.li>
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 flag is useful to force Nix to re-fetch cached flakes. Without it,
you cannot deploy from a non-local flake in quick succession, since the
caching causes the flake to not be re-fetched.
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.
- Fix paragraphs in option field texts containing Markdown.
- Fix generation of documentation for options with Markdown in
multiple fields.
- Support AsciiDoc in module option documentation.
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.
This enables nushell integration by default for direnv, similar to
bash/zsh/fish. The slightly verbose way of setting this is to ensure
that peoples' existing nushell configuration isn't overwritten, only
appended to, as would be the case if we just used the integration
example from the nushell docs:
https://www.nushell.sh/cookbook/direnv.htmlCloses#3520
When building from a flake, `nix build` hides the build output by
default, with a `-L`/`--print-build-logs` option to show it. Pass this
option along from `home-manager` if the user provides it.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Previously the nushell module did not differentiate between Linux and
Darwin when deciding where to place config files, whereas nushell
does. This commit fixes that.
The default value for `xsession.windowManager.herbstluftwm.tags` is an
empty list, but the config file uses `builtins.head` on it, which causes
an error upon evaluation. With this change the tags configuration is
skipped if the list is empty.
Depending on DHCP settings you might end up with different output from
running `hostname`. Eg, your local hostname is `mylaptop`, and your
home router is configured with a local domain of `.hoome.arpa`. In
this case:
$ hostname
mylaptop.home.arpa
$ hostname -s
mylaptop
If you then go to cafe which has its router configured with `.lan` as
its local domain. Then, if your DHCP settings accept the local domain
from the router,
$ hostname
myalaptop.lan
$ hostname -s
mylaptop
With the pre-existing behaviour, if you had a
`"me@mylaptop.home.arpa"` entry in `outputs.homeConfigurations`,
running `home-manager switch` would fail:
$ home-manager switch
error: flake 'git+file:///home/me/.config/nixpkgs' does not provide
attribute 'packages.aarch64-darwin.homeConfigurations."me".activationPackage',
'legacyPackages.aarch64-darwin.homeConfigurations."me".activationPackage'
or 'homeConfigurations."me".activationPackage'
After this commit, you can put configuration in a `"me@mylaptop"`
entry in `outputs.homeConfigurations`, and everything will work on
either network.
The previous variant used IFD to generate the `JAVA_HOME` variable and relied on internal hooks of the `java` package, this failed for a user cross compiling their configuration.
This PR changes that and uses the `home` attribute, as documented in the very last sentence of the https://nixos.org/manual/nixpkgs/stable/#sec-language-java chapter.
The old trigger would actually never cause a restart since the path
doesn't change. With this change the trigger is now using the actual
configuration path in the Nix store, which depends on the content.
While this is created to match `himalaya`’s configuration API, this
could easly be reused for other programs that consume the email module
by concatination the strings.
The previous version linked the file into home, then sourced that. Since
nothing else expects that file to be there, this is unnecessary.
Additionally, doing so made it impossible to test a built config without
switching, e.g. using `XDG_CONFIG_HOME=… nvim` or `nvim -u`. This
remedies that, at least for this particular reference.
To test this, change from asserting contents of the config file to
actually starting nvim, outputting sentinel values, and then asserting
their values are present. This way it’s tested that nvim loaded the
config, rather than that some config is in a specific place.
This is all in one commit as the test, as written now, would not have
worked before since the previously hard-coded home path was not an
actual file in the test environment.
Specifically, inform the command about the absolute path of
dbus-daemon. Otherwise it will try running dbus-daemon from PATH,
which may not always work.
PR #3405
* ssh: add generic Match support for matchBlocks
Introduce conservative support for actual `Match`
blocks in ssh config.
"Conservative" means this PR doesn'tt try to process
the `match` expression and simply uses it as a string
provided by the user.
If set, `match` has precedence over `host` meaning
if both are set, `match` is used and `host` is ignored.
* Add news entry
* flake: Expose tests to allow running purely
The existing way to run tests with `nix-shell` relies on impure usage of
`<nixpkgs>`. This can lead to failures when the local nixpkgs is
incompatible with the locked one. I.e., where CI is passing but a
contributor may experience a failure.
So, expose tests as `devShells.tests` to use the locked nixpkgs and
allow easy invocation via `nix develop`.
* tests: Remove impure path
With Nix 2.10+ and pure evaluation mode e.g.
```
nix run nixpkgs/nixos-unstable#nixVersions.nix_2_10 -- develop -i .#tests.zplug-modules
```
this test would fail with:
> error: the path '~/.customZplugHome' can not be resolved in pure mode
Since the test only cares that it is a path, rather than anything about
its contents, use a dummy empty directory.
Rather than reject a configuration when this option is set, just
silently ignore it when the platform isn't darwin. The name makes it
obvious that it won't be applied outside of darwin, and this allows
people to use the same configuration between hosts without any special concern.
Co-authored-by: Nicholas Sielicki <git@opensource.nslick.com>
This commit allows imperative management of "urls" file. It can be
useful if "urls" file is treated as a secret.
With this change, it's possible to provision "urls" via Syncthing,
agenix, sops-nix or other means, while still managing Newsboat
declaratively.
`--experimental-backends` flag was removed in the recent released picom
v10. Using it now will result in the program exiting.
v10 also introduces its counter-part, `--legacy-backends`. However this
will be removed soon. Instead of adding this as an separate option, add
`extraArgs` option so for those that they want they can pass it manuall.
It is also more future proof.
Previously, this module was all-or-nothing with its pre-defined user
dirs. This allows e.g. `xdg.userDirs.desktop = null;` to opt-out of
some configuration while still benefiting from the rest.
Starting with state version 22.11 we completely reset the PATH
variable in the activation script. This is to avoid impurities and
unexpected results if the activation script accidentally uses a
command found in the user's PATH.
When using the new style profiles we get conflicts when trying to
replace the old `home-path` derivation. To avoid this conflict we
delete the old `home-path` before the install.
Unfortunately, `nix profile` does not yet have a equivalent for
`nix-env --set` and we have to do this hackish workaround. See
https://github.com/NixOS/nix/issues/6349
for the associated issue in Nix.
Fixes#2848
Add a new Thunderbird module that uses the configuration in
`accounts.email.accounts` to setup SMTP and IMAP accounts.
Multiple profiles are not supported at this point.
- The `XDG_SESSION_TYPE` environment variable is used by some applications and frameworks to
detect wayland sessions (i.e qt5/6, electron/chromium). It is set by wlroots since version 0.13.0 [1].
- Propagating `XDG_SESSION_TYPE` to the systemd user environment is necessary when processes launched by
services (e.g emacs) need to inherit the environment variable.
[1] - 90c8452959
Update notification popups are annoying when vscode/vscodium is
managed by Home Manager. However, as these settings also require the
configuration to be managed via `userSettings`, they are disabled by
default.
This commits adds a file `hm-version` to the generated generation
directory. This file will contain the release version, and if
available, the Git commit hash.
With this change, it's now possible to configure the default search
engine in Firefox with
programs.firefox.profiles.<name>.search.default
and add custom engines with
programs.firefox.profiles.<name>.search.engines.
It's also recommended to enable
programs.firefox.profiles.<name>.search.force = true
since Firefox will replace the symlink for the search configuration on
every launch, but note that you'll loose any existing configuration by
enabling this.
Specifically, if `tput colors` fails with an error we treat that as if
the terminal does not support colors.
Fixes#423
Suggested-by: PhotonQuantum <self@lightquantum.me>
This will cache the output of `passwordCommand` per authentication
realm.
Context: the `credentials` key in `sbt` is a `TaskKey[Seq[Credentials]]`.
In `sbt`, tasks are evaluated on-demand and their output is not cached.
This particular key is referenced by all submodules in a project. When
the command is relatively expensive (e.g.: `pass show foo`), this
results in several seconds of delay when doing basic things like
`compile` or `test` which makes this unusable without some kind of
caching.
sbt allows overriding the default repositories to use to resolve
dependencies. This is often used with proxies and/or private
repositories to host internal packages.
This change adds a `repositories` attribute to `sbt` to allow
specifying the values that will go in `~/.sbt/repositories` file.
To support the above change we also deprecate the `baseConfigPath`
option in favour of `baseUserConfigPath` which points one level higher
by default. This allows not using relative paths to refer to the
top-level configuration directory.
Also adds tests for the new option and the deprecation of the previous
one.
At commit [5666e6b9](5666e6b9fb),
broot refactored the content of the file `/resources/default-conf.hjson`
into multiple files under the directory `/resources/default-conf`, using
[`imports`](5666e6b9fb/resources/default-conf/conf.hjson (L152-L165))
to refer to other configurations.
This refactoring is effective since version 1.14.0 of broot.
After this refactoring, in `xdg.configFile.broot` (which defaults to
`~/.config/broot`):
- we need to copy all potentially referenced files (all files under
`resources/default-conf`),
- except we need to leave out `conf.hjson` which conflicts with the
`conf.toml` generated by home-manager (because broot [accepts both conf.toml and conf.hjson](https://dystroy.org/broot/conf_file/))
To implement this, we use `symlinkJoin` to create the content of
`xdg.configFile.broot` by merging multiple sources.
* broot: use freeformType for config
* broot: use defaults from upstream
closes#2395
* broot: generate shell function
* broot: add @dermetfan to CODEOWNERS
* broot: rename `config` option to `settings`
* broot: make example more idiomatic
Co-authored-by: Nicolas Berbiche <nic.berbiche@gmail.com>
Co-authored-by: Nicolas Berbiche <nic.berbiche@gmail.com>
We change the current logic: instead of writing an init.vim which loads
lua/init-home-manager.lua, we write an init.lua that sources init.vim
This commit also avoids writing any of these files if the plugins have
no config.
Some configuration options can take space separated strings; for
example `SSLVersions` can be configured with multiple allowed
versions.
SSLVersions TLSv1.3 TLSv1.2
This can now be represented in Home Manager.
SSLVersions = [ “TLSv1.3” “TLSv1.2” ];
In implementing this change, it uses oneOf for config type, as it is a
cleaner way to represent the union than the nested eithers
formulation.
Also add SSLVersions to test lists of strings in
`account.extraConfig`.
In #587, kalbasit introduce the `-i` flag so the sudo invocation would
run in an environment with `HOME` set to the correct value for the
target user. This was necessary to be able to set up multiple users
without interfering with the invoking user's `HOME`.
In #807, I switched to `-s` instead because I managed to get an
invalid shell set for my user by switching `useUserPackages` from
`true` to `false` which changes the location where packages are
installed and `~/.nix-profile/bin/<my-shell>` was no longer valid.
This was based on the assumption that `SHELL` would be set to some
sensible value by Home Manager at this point. This turned out to be
false as reported in #2900.
In 0ced6d6d (this commit's parent at this time), I explicitly set
`SHELL` to `${pkgs.bash}` so it is definitely set to a good shell when
invoking the activation script.
However, #807 broke activation for multiple users, the original
motivation for `-i`, as reported in #2856. I fixed this in #2857 by
additionally passing `--set-home`.
Further discussion with rycee in #3040 made me realize that the
activation script already has a good Nix store bash shebang. So all
the problems have been caused, not by the shell used for the
activation script but by sudo trying to use a different shell at all.
`-i` uses the shell set in the `passwd` file for the target user, but
this can become invalid as happened to me. `-s` uses either `SHELL` if
it's defined or the invoking user's shell as set in the `passwd` file.
By explicitly setting this to a shell provided by Nix we make sure
we're not trying to launch a non-existent shell. However, we're
clearly already running in an existing shell and because of
`--set-home` we can activate other users properly so there's not
actually any need to try to have sudo start a different shell first,
it just adds an extra process that then goes on to run the activation
script with a good bash because of the shebang.
Dropping `-s` altogether and keeping `--set-home` should avoid all of
these issues.
In #807 I changed the flag passed to `sudo` from `-i` to `-s` so
`sudo` wouldn't use a non-existent shell defined in the `passwd` file.
kalbasit also reported in that PR that `-i` didn't work for them
anymore on an M1 Mac, presumably because Apple changed something in
newer versions of macOS.
Some users reported that this broke the behavior for them because
`SHELL` was set to a path that didn't even exist on their system. It's
unclear how this came to be but it shows that my assumption that
`SHELL` would be set to a reasonable shell by Home Manager at this
point in the activation is false.
As a way around this problem we can explicitly set `SHELL` when
running the activation script to a value that we know will be good,
like `${pkgs.bash}`.
One change in behavior this causes is that the activation script will
always be run by bash, not the user's shell. If the script is
generated by Home Manager this is fine since it can be generated
taking into account the supported set of functions and behaviors. If
the intent is for the activation script to possibly be run by non-bash
and even non-POSIX shells, like tcsh, ksh or Xonsh, then this fix will
not suffice. Turns out this is indeed an assumption made by Home
Manager, so this is the proper behavior.
Fixes#2900
If the user has enabled the XDG user directories module then we can
use the XDG music directory in the MPD module. Otherwise we'll leave
the option undefined so that the user is forced to define the
directory to use.
This applies to state version 22.11 and above.
Fixes#3225
Instead of referencing the `HOME` environment variable, use the
`home.homeDirectory` option. This allows other modules to reference an
XDG user directory without having to support shell syntax.
Units with
Install.RequiredBy = [ target ]
set will now be linked in the
${target}.requires
directory. Similar to how `Install.WantedBy` already causes a link in
the
${target}.wants
directory.
The `tag.gpgSign` config option was added in Git 2.23.0 and seems like
it should be set in addition to `commit.gpgSign` when
`programs.git.signing.signByDefault` is enabled
The GNU Privacy Guard 2.3 man page for `gpg-agent` describes the
`--grab` and `--no-grab` options as follows:
> Tell the pinentry to grab the keyboard and mouse. This option should
> be used on X-Servers to avoid X-sniffing attacks. Any use of the
> option --grab overrides an used option --no-grab. The default is
> --no-grab.
Therefore Home Manager should explicitly output `grab` when
`cfg.grabKeyboardAndMouse` is true. Previously Home Manager emitted
`no-grab` when `cfg.grabKeyboardAndMouse` was false.
PR #3192
everything is now covered by other settings that are more user friendly
than this big opaque attrset.
Also 'configure' wont do anything with nixpkgs-unstable the way HM
configures neovim. so no need to keep it, the deprecation warning is > 1
year old.
This adds support for configuring email accounts, with automatic smtp, imap,
sendmail (msmpt) and maildir (mbsync, offlineimap) setup in aerc,
via `accounts.email`.
- Fix name of file generated by `$ nix-build -A docs.manPages`.
- Note "Capitalize the subject line" as an exception to the seven
rules. Not even the example commit message (closely below this
change) follows this rule.
The XDG Desktop Entry spec mentions that multiple values per key may be
optionally terminated by a semicolon. An example for this is the Firefox
desktop file, which has no trailing semicolon. This breaks the sed regex
used in `mimeAssociations`.
Fix the regex by matching the end of string, optionally preceded by a
semicolon, or any other semicolon. This makes it work with both
semicolon-terminated and non-semicolon-terminated desktop files.
In the scenario where some XDG user directory is a symlink defined by
`home.file`, we want the symlink to be created before we try to
`mkdir -p` that directory, as it will then silently succeed. On the
other hand, if we create the directory first, creating the symlink
will fail.
We lose nothing by doing this as `linkGeneration` creates the
directories it needs.
This patch follows a similar patch[1] in nixpkgs. With this patch,
fish can complete manpages for programs installed through
home-manager, e.g., using home.packages.
[1]: https://github.com/NixOS/nixpkgs/pull/91794
Specifically,
- directly export `modules/lib/dag.nix` instead of renaming
attributes,
- run through utilities to reuse code where possible,
- expose `lib.hm.dag.isEntry` and reuse it in
`modules/lib/types-dag.nix`,
- reuse utilities through `lib` set instead of passing imports to
functions, and
- eta reduction of `map`, `entryAnywhere`, `entryAfter` and
`entryBefore`.
bash and zsh apparently handle command substitution slightly differently
than fish. in bash/zsh:
$ export FOO=x
$ FOO=y echo $(sh -c 'echo $FOO')
x
whereas in fish:
$ export FOO=x
$ FOO=y echo $(sh -c 'echo $FOO')
y
so we have to assign $SHELL within the substitution for bash and zsh.
The `services.picom.opacityRule` option was renamed to
`services.picom.opacityRules`.
This was missed in #2939
Signed-off-by: Sumner Evans <me@sumnerevans.com>
swayidle executes commands using "sh -c" and so its PATH must contain
a shell. This adds such PATH entry to the environment of the systemd
service.
Fixes#2811.
Removes the `uniq` constraint on `after` and `before` so that we can
merge multiple definitions for the same DAG entry:
{
dag = mkMerge [
{
foo = lib.hm.dag.entryBefore [ "bar" ] {
# definition 1
};
}
{
foo = lib.hm.dag.entryBefore [ "qux" ] {
# definition 2
};
}
{
foo = {
# definition 3
};
}
];
}
In this example `foo` will come before `bar` and `qux`.
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.
Adds option settings, which writes settings to
.config/udiskie/config.yml.
Note, the option takes precedence against other options like notify,
automount or tray if they are configured in settings.program_options.
This simplifies the code a bit and avoids using experimental Flake
functionality. If Flakes become stable before NixOS 22.11 then we can
consider having nmd and nmt as Flake inputs. Maybe could then also
avoid the need for flake-compat.
Remove `stateVersion`, `username`, and `homeDirectory` as they can be
set in the configuration directly. Together with the previous commit,
this makes setting `stateVersion` explicitly mandatory.
Also replace `configuration` by `modules`, which expects a list of
Home Manager modules.
Also remove `system` which was made useless by #3028.
Currently we're maintaining a "mock" module made of sink options,
which requires updating whenever the definitions in the
nixos/nix-darwin modules change.
Instead, set `_module.check` to false so that definitions in those
modules are simply ignored.
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
The user should always explicitly set the state version they wish to
use. Indeed, the configuration generated by the Home Manager install
script has set this option for a long time. This removal should
therefore not affect many users.
Add services.emacs.startWithUserSession boolean to indicate that Emacs
must be started with the systemd user session. This is true by default
unless socket activation is also true.
In the past, the user had to choose between socket activation (to get
the Emacs service started when the user uses emacsclient) and
immediate start with the user session. When choosing immediate start
over socket activation and if the Emacs service is stopped at some
point, using emacsclient would start a new Emacs daemon but the
service would still be turned off. This situation would prevent
`home-manager switch` from completing successfully because it wouldn't
be able to start the Emacs service as Emacs is already running.
This new setting makes it possible to have both socket activation and
immediate start at the same time. In this scenario, Emacs is started
with the user session and, after the Emacs service is stopped, using
emacsclient starts the service again.
This new settings also makes it possible to have neither socket
activation nor immediate start.
* Add flake.lock and clean up flake.nix
Add a lockfile to work around https://github.com/NixOS/nix/issues/6541
(and because it's a good idea anyway).
Also use flake-utils, and restrict ourselves to the five platforms
supported by nixpkgs. Otherwise, the IFD for nmd fails on weird
platforms. This fixes `nix flake check`.
Remove the redundant `apps` output, see https://github.com/nix-community/home-manager/pull/2442#issuecomment-1133670487
* nixos,nix-darwin: factor out into a common module
* nixos,nix-darwin: make `home-managers.users` shallowly visible
Make sure the option is included in the NixOS/nix-darwin manual (but the
HM submodule options aren't).
Also add a static description to the HM submodule type so that we don't need to
evaluate the submodules just to build the option manual. This makes
nixos-search able to index the home-manager flake.
Also clean up some TODOs.
* flake: add nmd and nmt
This avoids having to use `pkgs.fetchFromGitLab` in an IFD, which causes
issues when indexing packages with nixos-search because `pkgs` is
instantiated with every platform.
The `getmail` package will soon be removed from nixpkgs. The
`nixos-unstable` channel already has it removed and using the service
will result in:
error: getmail has been removed from nixpkgs, migrate to getmail6
Upgrade to the getmail6 package which is already available and backwards
compatible.
M_SHARE is not a valid column on Darwin. It seems that previously htop
ignored unknown columns, but the current version does not display all
subsequent columns.
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.
- Change the example value of `gtk.theme.package` from
`pkgs.gnome.gnome_themes_standard` was an alias that was removed on 2022-01-13,
`pkgs.gnome-themes-extra`, which references the actual package.
- Change the example value of `gtk.icon.package` from `pkgs.adwaita-icon-theme` to
`pkgs.gnome.adwaita-icon-theme`, as this package is in the `gnome` package set.
* 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.
This module adds basic support for configuration specializations.
These allow the user to build multiple alternative configurations that
should be part of the same generation.
In esoteric setups, automatically setting GPG_TTY to current tty is not
desired on every shell startup. This change adds configuration options
to allow user to disable that if desired.
Neomutt will run the given command (which can be a string or a path)
and take the output from stdout and use it as the signature for your
email.
Co-authored-by: Nicolas Berbiche <nicolas@normie.dev>
Without this the journal will be filled by
xscreensaver[468297]: sh: line 1: xscreensaver-command: command not found
xscreensaver-systemd: 12:29:22: exec: "xscreensaver-command -quiet -deactivate" exited with status 127
Constrain the pgrep command to only return results for the current user.
Additionally, quote the socket variables to prevent splitting.
Previously, if multiple users on a system were running `sway`, the
`pgrep` used in finding `swaySocket` would return multiple results. As a
result, reloads of sway would fail.
Fixes#2912.
This commit appends system-wide icon and pixmap directory and the icon
directory in the home-manager profile to the XCURSOR_PATH session variable
for the generic linux target. This is necessary because the default prefix
for libXcursor resolves to the Nix store which excludes the aforementioned
directories from being searched for cursor themes. [1]
[1] - https://github.com/nix-community/home-manager/pull/2891#issuecomment-1101064521.
This convenience function allows automatic assignment of a package's
associations to `xdg.mimeApps.defaultApplications`.
For example,
xdg.mimeApps.defaultApplications =
config.lib.xdg.mimeAssociations [ pkgs.gnome.evince ];
Co-authored-by: Ryan Trinkle <ryan@trinkle.org>
`modulesPath` is usually used with antiquotation
(`"${modulesPath}/some-module.nix"`). Since antiquoted paths are copied
to the Nix store, one must explicitly do `"${toString
modulesPath}/some-module.nix"` to avoid that. Ideally `modulesPath`
should be a string to avoid this. Note that `modulesPath` is already
defined as a string in <home-manager>/modules/default.nix and
<nixpkgs>/nixos/lib/eval-config.nix.
When processing `publicKeys` entries, handle entries that contain
multiple public keys (i.e. gpg --show-key returns multiple `pub`
lines) properly, setting the trust level for each key.
PR #2897
This makes it a lot easier to access the `pkgs` that would be used to
build the home configuration, e.g.
nix build ./dotfiles#homeConfigurations."user@host".pkgs.vim
This is useful as it allows access to a Nixpkgs that has been
instiantiated with config and overlays.
Removed by upstream since commit:
bcbc410c92
This commit is included since v9 release:
https://github.com/yshui/picom/releases/tag/v9https://github.com/yshui/picom/releases/tag/v9-rc1 (the actual changelog)
While this doesn't break the config per see, it results in the
following warning in the logs:
[ DD/MM/YYYY HH:MM:SS.mmm parse_config_libconfig WARN ] The
refresh-rate option has been deprecated. Please remove it from
your configuration file. If you encounter any problems without
this feature, please feel free to open a bug report
Beside the above change we also remove an old workaround and also
write the configuration file to a well-known location in the user's
home directory.
The code that is being evaled without the `--print-full-init` flag is
this:
```sh
__main() {
local major="${BASH_VERSINFO[0]}"
local minor="${BASH_VERSINFO[1]}"
if ((major > 4)) || { ((major == 4)) && ((minor >= 1)); }; then
source <(/nix/store/...-starship-1.3.0/bin/starship init bash --print-full-init)
else
source /dev/stdin <<<"$(/nix/store/...-starship-1.3.0/bin/starship init bash --print-full-init)"
fi
}
__main
unset -f __main
```
This code checks for bash version >= 4.1 , which has been released in
2009. Since this version is widely unavailable in nixpkgs, we can skip
one program invocation and directly call `starship init bash
--print-full-init`.
This is achieved by generating the Home Manager configuration
file as `~/.config/task/home-manager-taskrc`, and including that
file into ~/.config/task/taskrc.
Fixes#2360
Co-authored-by: mainrs <5113257+mainrs@users.noreply.github.com>
Co-authored-by: Nicolas Berbiche <nicolas@normie.dev>
* systemd: fix creation of user service unit files
* helix: fix failing test due to file output format change
Co-authored-by: Nicolas Berbiche <nicolas@normie.dev>
It can happen in some cases that home-manager first runs before gpg
creates its homedir, and it creates it with 755 permissions which the
user then needs to change by hand.
Do this in the module instead: before linking files, make sure the
homedir exists, and if it doesn't, create it with the right permissions.
Changed option types to `either str path` to allow using path values.
The related session variable is defined for the default and the extra
user directories now.
Changing from `sudo -i` to `sudo -s` messes up activation when multiple
users are managed. `--set-home` should have similar behavior to `-i` in
that the activation script is run from the user's home directory.
Fixes#2856
Currently activation is run with `sudo -i` this defaults to the user's
login shell. This can lead to problems if the user's shell isn't set
properly.
By passing `-s` rather than `-i`, `sudo` runs `activate` in `SHELL`
instead. We assume that at this point in the activation `SHELL`
contains the path to a bash in the nix store. This should always be a
valid shell to run the `activate` script with.
From the `sudo` manual it seems like this cannot be fixed if `SHELL`
isn't set at this point or by passing a command to `-s` because that
command is then passed to the user's shell.
This makes definitions like
home.activation.foo = mkIf false "bar"
work, where previously they would complain about
`home.activation.foobar.data` being used but not defined.
The crucial part is that we don't call `convertAllToDags` in
`dagOf.merge`, because we need to process `mkIf`/`mkMerge` properties
first. So we let `attrEquivalent.merge` do its job normally, but give
it a type `dagEntryOf` that does the conversion.
Ideally this shouldn't require so much boilerplate; I'd like to
implement something like
types.changeInto dagContentType elemType dagEntryAnywhere
in Nixpkgs.
Before enabling dconf in Home Manager, dconf must be enabled in system
config.
Otherwise it will fail like this:
```
$ home-manager switch
Starting Home Manager activation
Activating checkFilesChanged
Activating checkLinkTargets
Activating writeBoundary
Activating installPackages
replacing old 'home-manager-path'
installing 'home-manager-path'
Activating dconfSettings
error: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit dconf.service not found.
```
This would give the error "attempt to call something which is not a
function but a list" given that `optionals a b` returns a list. `indent`
is the one taking this empty set as second argument.
The conversion from `concatMapStrings` to `concatStringsSep` introduced in https://github.com/nix-community/home-manager/pull/2481
creates an unintended behavior change where the formatted config does not end in a newline.[1]
This is problematic for manipulation at the Nix level. In particular, this cause a regression in
the generation of gtk2 settings due to concatenated of the formatted config and `gtk2.extraConfig`
without a newline in between.
This commit restores `concatMapStrings` to match the previous behavior and adds a newline to
the final string for the generated gtk2 config. The test case for gtk2-basic-config
was also updated to check behavior at concatenation boundaries.
[1] - https://github.com/nix-community/home-manager/pull/2481#discussion_r830648706
If set to true, desktops configured in `monitors` will be reset every time
the config is run.
If set to false, desktops will only be configured the first time the config is run.
This is useful if you want to dynamically add desktops and you don't want them
to be destroyed if you re-run `bspwmrc`.
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
* gtk: add cursor theme configuration
- Added the `cursorTheme` under the gtk module.
- Added tests for the gtk3 settings file generation, and renamed
the gtk2 unit test expected file for clarity.
- Added guard against generating a blank `gtk.css` when `cfg.extraCss`
is empty.
- Replaced `concatMapStrings` calls with `concatStringsSep`. The library function
`concatMapStrings` generates an intemediate list which is then passed to
`concatStringsSep`, As we are not performing other transformation except
the addition of newlines, a direct call to `concatStringsSep` is sufficient.
- Updated description of examples to be more general "~/.config" -> "$XDG_CONFIG_HOME".
- Update helper functions `toGtk3Ini` and `formatGtk2Option` to use the library
function `boolToString` and escape the separator in the key name.
* xcursor: delegate GTK cursor settings to gtk.cursorTheme
- Added deprecation warning for GTK settings in the `xsession.cursorTheme` module.
- Modified config section to use `gtk.cursorTheme` for GTK cursor settings.
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.
Previously, if a process inside a foot client triggered the OOM killer,
systemd would also kill the parent unit, namely the foot server.
This is not ideal if a user has a lot of clients attached, and it's
usually not the terminal emulator's fault that a process inside it has
ended up using all the available memory.
There seems to be some changes on how wrapped binaries are implemented
on nixpkgs. This broke the nnn tests since the tests were coupled with
the old implementation.
This commit fix the tests, and also make it less coupled by just testing
if the bookmarks/plugins/environment variables are available.
This patch moves both home.sessionVariables and
programs.zsh.sessionVariables from .zshrc to .zshenv. Additionally,
these two kinds of session variables will not be sourced more than
once to allow user-customized ones to take effect.
Before, session variables are in .zshrc, which causes non-interactive
shells to not be able to get those variables. For example, running a
command through SSH is in a non-interactive and non-login shell, which
suffers from this. With this patch, all kinds of shells can get
session variables.
The reason why these session variables are not moved to .zprofile is
that programs started by systemd user instances are not able to get
variables defined in that file. For example, GNOME
Terminal (gnome-terminal-server.service) is one of these programs and
doesn't get variables defined in .zprofile. As a result, the shells it
starts, which are interactive and non-login, do not get those
variables.
Fixes#2445
Related NixOS/nixpkgs#33219
Related NixOS/nixpkgs#45784
This file is not formatted before and is excluded by ./format, so I don't format it.
Currently translated at 78.5% (11 of 14 strings)
Translate using Weblate (Japanese)
Currently translated at 100.0% (32 of 32 strings)
Translate using Weblate (Japanese)
Currently translated at 35.7% (5 of 14 strings)
Translate using Weblate (Japanese)
Currently translated at 84.3% (27 of 32 strings)
Translate using Weblate (Japanese)
Currently translated at 25.0% (8 of 32 strings)
Co-authored-by: Narazaki Shuji <shujinarazaki@protonmail.com>
Translate-URL: https://hosted.weblate.org/projects/home-manager/cli/ja/
Translate-URL: https://hosted.weblate.org/projects/home-manager/modules/ja/
Translation: Home Manager/Home Manager CLI
Translation: Home Manager/Home Manager Modules
Currently translated at 25.0% (8 of 32 strings)
Translate using Weblate (Japanese)
Currently translated at 6.2% (2 of 32 strings)
Add translation using Weblate (Japanese)
Co-authored-by: Heman Gandhi <hemangandhi@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/home-manager/cli/ja/
Translation: Home Manager/Home Manager CLI
When an hook is defined, a side effect was the creation of the
${notmuchIni.database.path}/.notmuch/ directory by home-manager. If
the Xapian database does not exist yet but this .notmuch directory
exists, Notmuch is confused and throws an error when `notmuch new` is
run (while this should create the database the first time).
This commit changes the hooks paths to $XDG_CONFIG_HOME where Notmuch
expects them (see notmuch-config(1)) instead of inside the maildir
database directory.
It also moves the configuration where Notmuch expects it, but the
$NOTMUCH_CONFIG environment variable is kept for backward
compatibility.
In the manual:
* Add chapter Nix Flakes
* Add links to sections of chapter "Using Home Manager"
In README.md:
* Remove section "Nix Flakes"
* Add manual reference at the buttom of section "Installation"
Plugins now accept a "type" element describing the language (viml, lua
, teal, fennel, ...) in which
they are configured.
The configuration of the different plugins is aggregated per language
and made available as a key in the attribute set `programs.neovim.generatedConfigs`
For instance if you want to configure a lua package:
```
programs.neovim.plugins = [
{
plugin = packer-nvim;
type = "lua";
config = ''
require('packer').init({
luarocks = {
python_cmd = 'python' -- Set the python command to use for running hererocks
},
})
'';
}
]
```
and you can save the generated lua config to a file via
```
xdg.configFile = {
"nvim/init.generated.lua".text = config.programs.neovim.generatedConfigs.lua;
};
```
- Add support for command line arguments, this allows arguments to be
persistently set if needed (i.e workaround hardware bugs or enabling
certain flags).
- Document setting a custom package will nullify the `commandLineArgs`
option.
- Fix `mkRemovedOption` assertion from being apply even when the
`extensions` option is unused for google chrome modules.
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.
Currently translated at 96.8% (31 of 32 strings)
Translate using Weblate (German)
Currently translated at 15.6% (5 of 32 strings)
Add translation using Weblate (German)
Co-authored-by: mainrs <github619064@zerotask.net>
Translate-URL: https://hosted.weblate.org/projects/home-manager/cli/de/
Translation: Home Manager/Home Manager CLI
- The check did not account the default value of `settings.modules` to be `{}`.
The default value was changed to null.
- The `settings.modules` option is now hidden from the docs.
Specifically,
- include system-wide Nixpkgs channel so `NIX_PATH` solution also
works on multi-user installations;
- additionally link to Nix Discourse reply for more information on
`NIX_PATH`; and
- remove note about relog on NixOS since all the channels in
`~/.nix-defexpr/channels/` are included by default, so the Home
Manager channel should be picked up automatically.
Based on nixpkgs commit c4b3aa62608d592d8a983be685f7e82000f4de30
stringBool is not needed because makeDesktopItem handles converting boolean parameters to string,
and noDisplay and prefersNonDefaultGPU parameters have been added.
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.
The empty configuration test for the bottom module introduced as of https://github.com/nix-community/home-manager/pull/2323
is not cross platform. Specifically, it silently fails under a darwin environment due to
the configuration file not being generated at $XDG_CONFIG_HOME. This PR add cross platform support
by specifying the platform-dependent configuration directories to check. The expected unit test data
was also extracted to a separate file to differentiate between test data changes and
changes to the test itself.
Write YubiKey token IDs in the format yubico_pam expects. See
https://developers.yubico.com/yubico-pam/ for details. Also refer to
the NixOS option security.pam.services.<name>.yubicoAuth.
Closes#2502
Currently, dot directories and XDG base directories are used
inconsistently in the Home Manager option declarations. This creates
ambiguity for the user as to where the location of the file should be
albeit this is rarely encountered in practice as it is sufficient to
read upstream documentation. The rationale is to make declarations
consistent and make a clear distinction between hardcoded and modular
specifications.
References to ~/.config in relevant nixpkgs modules were untouched as
the location is hardcoded upstream[1]. Furthermore, modules of
programs which do not follow XDG specifications were also untouched.
Generalization of tilde(~) expansions to $HOME were also considered,
however there isn't sufficient rationale despite the use of $HOME
being more universal. The expansion is standardized in POSIX[2] and is
essentially portable across all shells, thus there is no pragmatic
value to introducing the change.
[1] https://github.com/nixos/nixpkgs/blob/master/pkgs/top-level/impure.nix
[2] https://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_01
Previously, home-manager would not create a user.js for a certain
profile if profile.bookmarks was not empty but
profile.settings was empty and profile.extraConfig was an
empty string.
The `style` option now also accepts a path instead of a text
configuration.
Keeping up with new Waybar options is annoying, so make the module a
freeform module.
The `modules` option will be removed in release 22.05.
The logic to generate warnings for modules and everything was
removed. I don't want to maintain the code that generates these
warnings anymore.
Two misplaced quotations were introduced in `doBuild` by https://github.com/nix-community/home-manager/pull/2501, which
caused the parameter expansion of DRY_RUN to include an extraneous tab. Since the flake uri is passed
later into the command, Nix assumes the whitespace sequence as the flake uri and returns that it is not
a valid flake reference.
This PR removes the misplaced quotations in `doBuild` and also places the flake uri as the first argument for
calls to `doBuildFlake` for consistency with `doBuildAttr`. Placing the uri first in the command line also guards
against possible security issues if arbitrary uris are expanded prior to the user given uri.
Since Rofi 1.7.1 (specifically davatorium/rofi@0e70d8a), the deprecated
`theme` option in the `configuration` section no longer works. For 1.7.0
and up, `@theme "name"` is supposed to be used *after* the
`configuration` block.
Currently, the `buildNews` and `doBuildAttrs` are always called
unconditionally even if a flake configuration is specified. This cause
it to always fail prior to the actual build performed by `doBuildAttrs`
because `setConfigFIle` can not find the home-manager configuration file.
As a result, an error message specifying no configuration file is shown.
Furthermore, if a user has remnant legacy configuration, the `doSwitch` and
`doBuild` functions will effectively build the activationPackage twice, with
the legacy configuration overriding the flake configuration.
A conditional check for FLAKE_CONFIG_URI was added to mitigate this by building
the legacy configuration when no flake configuration is present. There is one
exception which is when a flake configuration exists in the default location, where
the user can not build the legacy configuration as along as the file is present.
However, the tradeoff is acceptable as it matches current behavior when FLAKe_CONFIG_URI
is set for instantiation, and an user is unlikely to simulataneously switch
between the two mechanisms.
An abstract function for building flakes `doBuildFlake` was created to match
`doBuildAttrs` for manageing options and build flags.
The --no-write-lock-file flag was removed from the --debug case as it is already
matched previously at the --recreate-lock-file case.
Home Manager can be ran with
`nix run --no-write-lock-file github:nix-community/home-manager`.
This is useful for people who want to try out Home Manager or,
want to bootstrap their home-environment.
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.
Nixpkgs switched to OfflineIMAP version 8 which means that Python 3 is
now used instead of Python 2. As a result, get_pass() now returns a
byte array instead of a string and the argument to get_pass() must be
a byte array too. See
https://github.com/OfflineIMAP/offlineimap3/issues/103.
Add an option to set custom `$ZPLUG_HOME`. Changing it with
`home.sessionVariables` doesnt work, since it has to be exported
before Zplug is initialised
If the keyboard configuration is an empty set, don't run the setxkbmap
service.
The default values for all keyboard options are null or empty so long
as the state version is set to 19.09 or higher (21.05 being the latest
version).
Before this change, a warning would be printed to the console if you
tried to manage a file in a path containing a space. For example,
`vscodium`'s `userSettings` file on Darwin is at
`~/Library/Application Support/VSCodium/User/settings.json`.
Rationale:
As of release 1.1.2[1], the configuration ini file supports
declaration of the `[main]` header as an alternative to global
properties by enumerating all sections and mapping each to the
respective parsing function. Global properties will still be parsed
correctly by fnott however generation adds unnecessary complexity to
the module. This commit removes the need for global properties
generation.
Changes:
- Fixed the FIXME at L118.
- Cleaned up unneeded let bindings.
- Changed the generation method to use the `pkgs.formats.ini` from
pkgs-lib instead of the raw `generators` library. This was done for
consistency and clarity as the `pkgs.formats.ini` is still required
for type declaration and uses `generators` internally.
- Removed `global-properties` testcase.
- Updated `example-settings` testcase.
[1] - https://codeberg.org/dnkl/fnott/releases/tag/1.1.2
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`).
Having either argument defined based on the OS is a problem when
trying to write generic Nix code.
The current workaround is to use accept both and specify a default
value for each argument:
```
{ config, lib, nixosConfig ? {}, darwinConfig ? {}, ... }:
let
osConfig = nixosConfig // darwinConfig;
in
{
# Do something with `osConfig`
}
```
With this commit, it becomes possible to do the following:
```
{ config, lib, osConfig, ... }:
{
# Do something with `osConfig`
}
```
- Add NIXPKGS_REV, so we can pass arbitrary revisions for testing (for
example, `release-21.05` so we can test backports).
- Add format target, that calls the format script.
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 is to better integrate with more advanced shell history managers
like McFly and Atuin. By initializing fzf first, we allow the history
managers to steal the C-r key binding from fzf.
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
kanshi configurations can have more than one exec statement in a
profile. This change allows services.kanshi.profiles.<name>.exec to be
a list of strings rather than a single string.
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.
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.
If the user has a running systemd session, source their environment
from the systemd manager and export a few variables in order to allow
activation scripts to reload applications on the fly.
The list of variables to export is arbitrary and could be extended in
the future.
Fixes#1399, fixes#2112.
Specifically, instead of
services.dbus.packages = with pkgs; [ gnome.dconf ];
we now recommend
programs.dconf.enable = true;
which does the same and more.
Currently, when a custom path is set for any of the XDG base
directories (i.e XDG_DATA_HOME, XDG_CONFIG_HOME, ...), the path will
be coerced into a string when consumed by other options such as
xdg.configFile et al. This causes the the given path to be copied to
the nix store which in the case of xdg.configFile et al, translate to
the file being written there as it is a absolute path.
Interestingly, the default base directories all work as intended as
they are encoded as a string.
This commit converts the option to a string regardless of whether it
is a primitive path or a string encoded path. This allows downstream
consumers to use the base directories in arbitrary way without
accidentally copying the content of the directory to the store. It is
implemented in a similar manner as how home.homeDirectory undergoes
string conversion.
The existing file-attr-name test was modified to test also custom xdg
base directories, and the home.file generation test was removed as
there is a dedicated test for this case in the files module. The test
case was renamed to file-gen to better reflect the new scope.
Make `gpgconf` only perform an import from derivation when the GPG
`homedir` is set to a non-default value, which probably isn't the case
for most users.
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.
- Change generation behavior to always generate a configuration file
and pass it explicitly to fnott, it enforces the module to be
hermetic instead of offloading the configuration selection to
heuristics.
- Various style changes.
- Fix issue where fnott would abort due to an invalid config file when
both the configFile and settings options are unset.
- Remove the empty-settings test as a configuration file is now
already generated.
Suggested-by: Robert Helgesson <robert@rycee.net>
The docs implied that fish was not really supported, but if fish is
managed by Home Manager, the generated config does use fenv to source
the session-vars file. Update the installation instructions and FAQ to
mention that fish does work, and mention fenv in the README.
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.
One of the things managed by the `home-manager-<username>` unit is the systemd
user directory `.config/systemd/user`. However, this directory needs to be in
place completely before systemd user sessions start up or the user sessions will
come up with an incomplete listing of enabled units, etc.
There was a race condition where nothing prevented
`systemd-user-sessions.service` from starting ahead of the systemd user
directory's initialization completing. This commit makes
`home-manager-<username>` finishes _before_ we start
`systemd-user-sessions.service` to avoid such race condition.
This issue was probably not all that noticeable in most cases, but when using a
non-persistent root config (i.e. tmp on / or
https://grahamc.com/blog/erase-your-darlings) the race condition triggering
causes all kinds of issues on each reboot.
* gpg-agent: local agent acting as ssh-agent should yield
This happens commonly if someone using home manager with gpg-agent
acting as ssh-agent on both machines.
@rycee brought up how gpg-itself has some support for agents on both
ends, but in that case one is forwarding the gpg-agent socket rather
than forwardning the gpg-agent-as-ssh-agent socket. There is no need to
forward both.
So I think this is a good default:
- Forward just gpg-agent socket and this doesn't matter.
- Forward just the ssh-agent socket and this does the right thing.
- Forward both sockets and now the ssh one takes priority instead, but
forwarding both was always a silly thing to do.
Fix#667
* Update modules/services/gpg-agent.nix
Co-authored-by: Nicolas Berbiche <nic.berbiche@gmail.com>
Co-authored-by: Nicolas Berbiche <nic.berbiche@gmail.com>
At the moment, only the inbox of each mail account is added to neomutt.
This inbox is always called "Inbox", so if you configure multiple
accounts, it is hard to know which one is which.
This change allows the user to specify a display name per account that
uses `named-mailboxes` under the hood.
Additionally this change now allows to add other folders than the inbox,
for example the Trash, Spam or Drafts folders to be added on a per-account
basis. Using extraOptions is not possible here, as those are lazily
loaded on mailbox open and thus would appear at the bottom and not sorted
by account.
This commit also changes the default sidebar format string to use %D
instead of %B because %B will ignore named mailboxes and show the folder
name instead.
Fluidsynth's systemd unit currently has a hard dependency on the
pulseaudio systemd service. Since fluidsynth can use other sound
services (e.g., pipewire-pulse), this should be configurable. This
commit adds the relevant option.
PR #2238
This allows running home-manager with --builders option passed through
to nix-build, which will then pass build execution to remote builders on
other machines.
This may be useful with relatively complex home-manager configurations
where building on a local machine is not feasible.
When the 'fields' setting is not set in htoprc, the htop program won't read any
of the settings. Provide a default value for fields in case it's not explicitly
set by the user.
* 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.
Expose the generated viml config, this has 2 advantages:
1/ user can choose to write the generated config to a file of its choice
2/ the user can prepend/append to the config before writing it
xdg.configFile."nvim/init.vim".text = ''
" prepend some config
${programs.neovim.generatedConfigViml}
" append some config
'';
NOTE: this was already possible with
xdg.configFile."nvim/init.vim" = mkMerge [
(mkBefore {
text = ''
" prepend some config
'';
})
(mkAfter {
text = ''
" append some config
'';
})
]
This adds two new options: 'programs.neovim.coc.{enable,settings}`.
These settings offer a simple interface over `xdg.configFile."nvim/coc-settings.json`,
using the standard Nix' syntax instead of a multiline string.
With
programs.taskwarrior.dataLocation = /absolute/path
(outside of $HOME) the current implementation wrongly creates
$HOME/absolute/path (due to how home.file is implemented).
Since taskwarrior creates the dataLocation automatically on first run,
there is actually no need for HM to create that directory.
Additional benefit, the .keep symlink that HM creates as a side-effect
no longer appears in the taskwarrior data directory.
Fixes#2207.
Before, loading a module would be guarded by an optional platform
condition. This made it possible to avoid loading and evaluating a
module if it did not support the host platform.
Unfortunately, this made it impossible to share a single configuration
between GNU/Linux and Darwin hosts, which some wish to do.
This removes the conditional load and instead inserts host platform
assertions in the modules that are platform specific.
Fixes#1906
* rofi: add support to plugins
* rofi: update package example
Co-authored-by: Sumner Evans <me@sumnerevans.com>
* rofi: Format package example
* rofi: Fix tests
Rofi will not try to install plugins using override when tests overlay
actual rofi package with empty scirpt
* rofi: Refactor
Co-authored-by: Sumner Evans <me@sumnerevans.com>
* xresources: Add path configuration option
This allows the user to move .Xresources somewhere else, which can help
with decluttering the home directory.
* xresources: Update xresources.path docs
* xresources: Fix formatting
The packaging in nixpkgs for obs plugins has changed and there's a
wrapOBS function.
The name of the plugins has also changed so the example needed updating
to reflect that.
Related: https://github.com/NixOS/nixpkgs/pull/125308
* 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
NixOS/nixpkgs@03310df843 disabled flake
support by default, so we now need to build a custom package and use it
if the user wants to `use flake` successfully. This should fix#2087.
* irssi: add ssl_cert option for servers
I was following these instructions
https://www.oftc.net/NickServ/CertFP/
and found that the `/server add -ssl_cert` option was needed.
This patch therefore adds an optional
`programs.irssi.networks.<name>.server.ssl.certificateFile` path.
Perhaps this could also be done with a `settings` attribute, but that
would probably require most of this module to be reworked.
* irsii: Add example-settings test case
`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`.
When running a socket-activated emacs service, we don't want emacs to
remove the socket file after exiting, because then subsequent
invocations of `emacsclient` won't be able to use the socket to start
emacs.service again.
Emacs 27 added Type=notify support and updated the service definition to
remove the use of `emacsclient' to kill the service. Emacs 28 changes
the `StartupWMClass' in emacsclient.desktop to `Emacsd'. Update our
emacs.service and emacsclient.desktop definitions to match upstream
changes.
When killing emacs.service, the socket is removed, and subsequently
starting the service manually results in a service without a socket.
Prevent this by adding `RefuseManualStart=true' to the service's Unit
definition.
Drop Emacs 26 support as it is no longer shipped in nixpkgs. Update the
tests to verify the following configuration scenarios:
- Emacs version: 27, 28
- Socket activation: disabled, enabled
* 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>
Pass meters for formatting in a list of attrsets so that ordering can be
preserved. In addition provide some mode-specific functions to create these
attrsets, to make for a bit nicer config.
This fixes#2060.
Previously, the comparison would not handle directory comparison
correctly, always finding that the source and target differed. This
would trigger the `onChange` script on each activation.
Fixes#2004
* isync/mbsync: replace master/slave with far/near
isync/mbsync: update tests to match new changes
* isync/mbsync: use mkRenamedOptionModule to alert user to near/far change
* isync/mbsync: use warnings to alert about master/slave far/near change
Fix capitalization
isync/mbsync: fix nitpicks
* isync/mbsync: run format script
* isync/mbsync: include new test for expected master/slave warnings
* isync/mbsync: add news about changes
This target is for systemd units that require a system tray to be
running.
This also fixes taffybar.service: previously, systemd would consider it
to be active (running) before it was actually ready to accept tray
icons.
Previous patch on deprecation warnings broke use of old options due to function
call with too many arguments. This fixes the arguments so deprecation warnings
are properly traced while preserving old configuration options.
* 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.
This change makes the services created via the lieer module aware of the notmuch config created by the home-mangager notmuch module (which is stored in a non-standard location).
Without this change all the lieer services created by the lieer module failed for me, as they were unable to find the notmuch config.
* 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>
When profile installation fails during activation we'll print an extra
message that explain that, if the error is due to conflicting
packages, then it may be that the user has a manually installed copy
of the package.
Fixes#1244
Removed format exclusion exceptions for modules that are already
formatted correctly (that is, when running nixfmt, no changes happen) or
have been moved (in the case of i3.nix).
* 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
Attempting to build a flake configuration using `ssh.remoteForwards' results in
evaluation errors when `port' is undefined, as `!(entry ? port)' evaluates to
false. This was verified in the nix repl, and also occurs for `nix flake
check'.
Set optional attrs in `bindOptions' and `forwardModule' to `null' by default
and adjust the assertion to check for `null' instead of attr definitions.
* add service package option
* add waylandDisplay option dunst now supports wayland, and looks for WAYLAND_DISPLAY var to use it
Co-authored-by: @li:maisiliym.uniks <@li:maisiliym.uniks>
* flake: ensure passed pkgs with overlays and config is used
In the pkgsModule inside modules/modules.nix it will try to use the
<nixpkgs> from NIX_PATH if home.stateVersion is not set. This is not
available when using flakes so we need to require at least 20.09 and we
might as well default to that.
Also if you have added overlays and config to your pkgs it will be lost
so we need to transfer those as well.
This is an alternative to passing pkgs to extraSpecialArgs which will
break the usage of things like nixpkgs.config.packageOverrides.
* flake: add extraModules
If you want to add some extra home-manager modules, you have to mix them
with the configuration as such:
configuration = {
imports = [
emacs-config.homeManagerModules.emacsConfig
./home.nix
];
};
Instead of:
configuration = ./home.nix;
extraModules = [ emacs-config.homeManagerModules.emacsConfig ];
Which separates these two concerns.
Implements a --flake options for build and switch, along with the usual
flake related optons (for lock-files etc).
Configurations in the flake are automatically discovered in the
following order:
1. `outputs.homeConfigurations."$flake-uri"` (the `--flake parameter`)
2. `outputs.homeConfigurations."$USERNAME@$HOSTNAME"`
3. `outputs.homeConfigurations."$USERNAME"`
Make home-manager use default configuration from
~/.config/nixpkgs/flake.nix, if it exists and nothing else is
specified.
Co-authored-by: Nicolas Berbiche <nicolas@normie.dev>
If the configuration is `null`, the compiled configuration
`xmonadBin` should not be used and instead the WM startup command
should be set to the bare `xmonad` binary.
* Git: Make signing key id be optional
Thus by default the signing key is selected by commit’s author.
* Git: Add tests for config with and without signing key id
* Git: Format tests for signing key
* Git: Remove default value (null) for signing key
* Git: Update description for signing key
* neomutt: support list in binds.map
Closes#1245
Adds support for specifying programs.neomutt.binds[].map as a list. If
specified as a list, then the binds will be concatenated with a ",".
* neomutt: add deprecation warning for (binds|macros).map as string
Added note that specifying 'programs.neomutt.(binds|macros).map' as a string is deprecated. Instead, use the list form.
* neomutt: note deprecation warning in release notes
Added note that specifying 'programs.neomutt.(binds|macros).map' as a
single string is deprecated in favor of specifying it as a list
* neomutt: add assertion that map is not empty
Added an assertion that each 'programs.neomutt.(binds|macros).map' list contains at least one element.
Resolves#1843. Allows aliases to be expanded in initExtra, and adds a
visible bashrcExtra option for commands that should be run in ~/.bashrc
even by non-interactive shells.
* neomutt: Fix eval error when primary account not enabled
If neomutt is enabled for an account, but not the primary account, the
configuration will fail with "list index 0 is out of bounds".
This adds the first neomutt-enabled account as a fallback.
* neomutt: add regression test/update tests
The `libFiles` option allows Home Manager to manage additional files
for xmonad.
Also compile xmonad during configuration build time. This avoids the
need to compile the configuration during activation.
functionTo tries to evaluate functions too quickly and prevents modules
from accessing pkgs argument. fixes#1878.
Co-authored-by: Pacman99 <pachum99@gmail.com>
Fixed the breakage for prezto introduced in #1778.
The previous method created issues where certain configuration files would get
replaced by prezto's variants instead of being merged as before. This led to
issues like no config being loaded if `home.zsh.dotDir` was set.
The old method of loading these files has been restored. This fixes the issue.
When installing plugins, Home Manager expects plugins (packages) to have
a `pname` attribute.
This is not always the case, so fallback to `name` if `pname` is unset.
This allows me to use offlineimap with passwordstore. I guess nobody
uses a newline in their password?
Co-authored-by: Kerstin Humm <kerstin@erictapen.name>
Set the systemd user service to use "mixed" killmode, which lets waybar
stop its module scripts. This fixes issues where waybar blocks shutdown
until systemd sends a SIGKILL to waybar child processes.
This allows you to set a theme for Qt applications. For example, if you
want to use `adwaita-qt` theme to have uniform look between Gtk and Qt
applications, you can use it like this:
```nix
{
qt = {
enable = true;
platformTheme = "gnome";
style = {
name = "adwaita";
package = pkgs.adwaita-qt;
};
};
}
```
This makes Home Manager respect the NO_COLOR environment variable to
disable coloring from output generated by Home Manager.
This initiative can be found more on https://no-color.org/
The mailboxes must be a tuple of string or the string "ALL".
The generated value was broken if the mailboxes configuration was a list
of only one string (but not "ALL"): the generated expression ( "str" )
was not a tuple but a string.
Now, we always generate a tuple (by adding a comma, even with a list of
size one). Getmail works with the special value "ALL" whether it is a
in tuple or not, so this case is not specifically handled.
If a user using msmtp to send all their email, it would be preferred if
git used it as well.
The only settings necessary are to set the smtp server to the msmtp
binary and set envelop sender to true, which makes git call msmtp with
the -f flag to set the from address from the email.
Alot uses the first email in the config as primary email. Because the
order in which the email.accounts were sorted was alphabetical, the account
set to `primary = true` was not put first in the alot config and thus
not considered as primary email for alot.
This was fixed by sorting the email accounts again such that accounts
with `primary = true` come first.
The environment variable FZF_CTRL_R_COMMAND has never existed
and been support by fzf according to
`git grep FZF_CTRL_R_COMMAND $(git rev-list --all)` and
`git log -G FZF_CTRL_R_COMMAND`.
This allows users of the nixos and nix-darwin module to set shared modules
for all users and extra specialArgs to be available to home-manager modules.
The latter is named extraSpecialArgs just like the argument to
modules/default.nix.
This could be confusing since the the two are independent in code,
but they do mean the same thing so I think the name fits.
Darwin can now refer to the global system configuration if used as a module
through the special `darwinConfig` argument.
Co-authored-by: Nicolas Berbiche <nicolas@normie.dev>
Polybar's config format is a bit strange, and lists in particular are
annoying to handle. This enables using normal nix lists and nested
attrsets instead.
This change is not backwards-compatible, because the INI converter
converts lists of strings to space-separated values, and this does
something else. I expect that this is only relevant for the
`modules-left` etc bar setting, but that's enough to break things :(.
The `configure` option is not type checked and an artifact of how
nixpkgs is implemented.
We now have the equivalent options in home-manager and managing
interactions between the 2 systems complexifies maintainance of the
module.
Please use the other options at your disposal:
configure.packages.*.opt -> programs.neovim.plugins = [ { plugin = ...; optional = true; }]
configure.packages.*.start -> programs.neovim.plugins = [ { plugin = ...; }]
configure.customRC -> programs.neovim.extraConfig
The bash module always assigns a value to HISTFILE in the bashrc, even
when no value is explicitly set. This makes it impossible to tell bash
to use a different HISTFILE by setting the HISTFILE environment variable
HISTFILE=/tmp/bash_history bash
This changes the default value of programs.bash.historyFile to null, and
only writes the HISTFILE=... line to the bashrc if it is changed to
something else.
It was removed in nixpkgs and causes an error on rebuilds.
error: Your configuration mentions firefox.enableAdobeFlash. All plugin related options have been removed, since Firefox from version 52 onwards no longer supports npapi plugins (see https://support.mozilla.org/en-US/kb/npapi-plugins).
* zsh: update prezto path structure
The path structure was changed in Nixpkgs and this commit updates
the module to match.
Fixes#1773
* zsh-prezto: fix tests, small tidyup
Co-authored-by: Nick Hu <me@nickhu.co.uk>
Not every option is exposed by redshift/gammastep parameters, for
example gamma options are only exposed in configuration file. So this
PR refactors this module to generate a configuration file and pass it
to the redshift/gammastep using -c parameter.
This is a breaking change since there is no support for some of the
older options like `extraOptions`, but unless you use `extraOptions`
it should work without changes.
Not every option is exposed by redshift/gammastep parameters, for
example gamma options are only exposed in configuration file. So this
PR refactors this module to generate a configuration file and pass it
to the redshift/gammastep using -c parameter.
This is a breaking change since there is no support for some of the
older options like `extraOptions`, but unless you use `extraOptions`
it should work without changes.
The `SubFolders` option in mbsync controls the folder naming style in
the maildir. There are three different styles:
* Verbatim - <maildirPath>/top/sub/subsub
* Maildir++ - <inboxPath>/.top.sub.subsub (used by Dovecot)
* Legacy - <maildirPath>/top/.sub/.subsub
Previously, the `SubFolders` option was hardcoded to `Verbatim`. This
change allows configuration of the `SubFolders` option.
Add new options Darwin options:
- `targets.darwin.defaults`
This adds options for configuring macOS through the `defaults(1)` system.
This option can be used to manipulate a vast majority of user settings for macOS
and its applications.
This is implemented using freeform modules and includes additional descriptions
and type information for some useful options.
- `targets.darwin.keybindings`
This adds options for configuring the default keybindings for macOS text fields.
- `targets.darwin.search`
This adds options for configuring the default search engine for macOS.
If this commit now it is possible to define a custom theme directly
using Nix, like this:
```nix
{
programs.rofi.theme = {
"*" = {
background-color = "#000000";
border-color = "FFFFFF";
width = 512;
};
listview = {
cycle = true;
};
};
}
```
And this will be converted to the proper rasi format to be used in
rofi.
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
Closes issue #1725.
This allows mpv module to be customized with support for more advanced
features than the `programs.mpv.scripts` current support. For example,
with this change now this is possible:
```nix
{
programs.mpv.package = (pkgs.wrapMpv (pkgs.mpv-unwrapped.override {
vapoursynthSupport = true;
}) {
extraMakeWrapperArgs = [
"--prefix" "LD_LIBRARY_PATH" ":" "${pkgs.vapoursynth-mvtools}/lib/vapoursynth"
];
});
}
```
Since `programs.mpv.package` doesn't necessary reflect the final
derivation anymore (see #1524), we introduce `programs.mpv.finalPackage`
that has the resulting derivation.
This includes 2 tests:
- One to check if everything is alright with mpv
- Other to validate our assertion that package and scripts can't be
passed both at the same time
* docs: document recent mpv module changes
* mpv: add thiagokokada as maintainer
We currently check `isPath` and `isString` on crxPath and version
respectively, which is
1. pointless because the module system already does such checks, and
2. wrong because isPath means path literal; a derivation therefore is
not a path.
mu-cfind is meant to search for contacts within your contacts database and the emails that you have sent/received. The use of the --personal flag in that command is meant to filter for only emails that use your email addresses (which are all the ones you specify with the ${myAddresses} variable. Disregard what I said in #1623 (comment).
--my-address=<my-email-address>
specifies that some e-mail addresses are 'my-address' (--my-address can be used multiple times).
This is used by mu cfind -- any e-mail address found in the address fields of a message which also
has <my-email-address> in one of its address fields is considered a personal e-mail address. This
allows you, for example, to filter out (mu cfind --personal) addresses which were merely seen in
mailing list messages.
To initialize the database with mu init, the ${myAddresses} is not required to be passed to successfully initialize the database, but it is heavily recommended to do so.
To see the difference, in a safe location, run mu init --maildir=<path>, then mu index. You'll notice that "personal addresses" returns <none>, although the database will still work. However, mu cfind --personal will fail (as the personal contacts don't exist). Then run mu init --maildir=<path> --my-address=<address>, then mu index. Then you'll be able to search for contacts using mu cfind --personal.
When setting `...sway.package = null`, the default bar configuration
would throw an error trying to use the bar from the null package.
Logic is added to use the bar from `pkgs.sway` instead of `cfg.package`
if it is null.
Fixes#1714
This adds a "test.asserts" module that currently just provides a
convenient way to assert on the content of warnings. By default all
tests will assert that no warnings are given.
* neovim: write config in $XDG_CONFIG_HOME/init.vim
instead of wrapping the configuration, which has sideeffects
https://github.com/NixOS/nixpkgs/issues/55376
* fix: update test accordingly
I also made some modifications to the systemd service to match the [AUR version](https://aur.archlinux.org/cgit/aur.git/tree/goimapnotify@.service?h=goimapnotify) of `goimapnotify`. In particular, restarting is useful in case a network failure causes `imapnotify` to exit - that shouldn't mean that it stops trying when the network comes back up.
Previously, it was not possible to set an arbitrary tmux prefix since
CTRL was hardcoded in the module.
To avoid breaking existing configs, a new option was implemented that
conveniently uses the tmux terminology but defaults to null and does
not affect previous behavior when set to null.
The behavior for the shortcut option was not completely replicated,
i.e., it does not bind "b" to send-prefix but stick to the default of
the prefix binding sending prefix (C-b C-b instead of C-b b) and it
does not bind repetition of the prefix (C-b C-b) to `last-window`,
both of these bring the option closer to the default tmux
configuration.
Fixes#1237
Brave Browser is a chromium-based browser, too.
+ it use the same web store with Chromium and Google Chrome.
+ the machanism of installing extensions works, and it's verified on
my macOS box.
The current definition makes waybar wait for dbus.service, but that
never happens because dbus.service is started on demand by
dbus.socket.
Per systemd docs:
https://www.freedesktop.org/software/systemd/man/systemd.service.html#Implicit%20Dependencies
- Services with Type=dbus set automatically acquire dependencies of
type Requires= and After= on dbus.socket.
- Socket activated services are automatically ordered after their
activating .socket units via an automatic After= dependency.
Services also pull in all .socket units listed in Sockets= via
automatic Wants= and After= dependencies.
Removing Requisite/After makes the service properly start for me,
simply specifying Type=dbus is enough.
See #1370
- Change the `attrsOf unspecified` to `pkgs.formats.json`
- Add missing default modules
- Expand the `with lib` with every function used
- Add inline documentation about the generated warnings
Using the final package in the `onChange` block broke some use cases.
This restores the old behavior and instead solves the test
dependencies in a different way.
Fixes#1611
This reverts commit 7c3c64208e.
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.
The `invocation` is an optional attribute, so it doesn't make sense to
use it as the key in an attribute set. See
https://dystroy.org/broot/documentation/configuration/#verb-definition-attributes
Actually, `invocation` should not be defined when one wants to rebind
a built-in verb to a different key.
Also added documentation for the `key` attribute.
There exist mpv configurations which cannot be expressed in
`programs.mpv.config` currently. For example, it is impossible to use
multiple 'profile' attributes. This commit changes the way config and
profiles are parsed, using `lib.generators.toKeyValue` and
`lib.generators.toINI`, to allow for these kinds of configurations
through the use of `listsAsDuplicateKeys`.
This causes list values to be emitted as a list of key-value pairs
instead of a single key-value pair where the value is space separated.
This is useful, e.g., for socket units that would like to specify more
than one `ListenStream=` address.
The `accounts.email.accounts.<name>.neomutt.extraConfig` option is
included twice in the resulting config file for the account. One time as
part of the `mraSection`, one time as part of `accountStr` (`accountStr`
includes the `mraSection`). This removes that duplication. I opted to
keep the one in `accounStr`, since `extraConfig` doesn't necessarily
have anything to do with the `mraSection`.
The quoted `$EDITOR` causes errors when using values containing
arguments, eg. "code --wait". This is in contrast to the majority of
tools (git, etc.) that do support this usage.
Fixes#1496
In feh you can bind multiple keys to the same action, but Home Manager
only let you set a single key to an action. You can cheat and pass a
string with space-separated keys, but with this change you can pass a
list for each action to bind multiple keys to it.
Also adds a couple of tests.
Fixes#1366
* neovim: allow setting init.vim config alongside plugins
* neovim: add test for neovim plugins
* neovim: make pluginWithConfigType a have type submodule
`pgrep -x somecommand` exits with a non-zero status if it finds no
process running with the given name. When using home-manager as a
NixOS module, on boot (when sway isn't running) this script would
fail and then fail the unit since it seems the onChange scripts
are running with the -e switch.
This change ensures we're always returning a 0 exit status where we
attempt to get the pid of sway - we're only interested in either the
pid or an empty string, the exit status isn't important.
Adds a pet module without sync support as it makes no sense when
configuration is managed with Home Manager and the config would be
unwritable for pet anyway.
PR #1045
* 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>
The `ExecStart=` option of systemd must take arguments fully quoted.
That is,
"-sshargs=-i somekey"
and not
-ssargs="-i somekey"
Additionally, inside arguments passed to unison, `=` characters must
be quoted. After unquotation by systemd, one must have
-sshargs=-o Foo\=4
instead of
-sshargs=-o Foo=4
The apropos software is useful to get a list of manpages matching a
description or to get a list of all manpages. The latter feature is
used by Emacs to get manpage completion (`M-x man`).
To have apropos working, a database of all available manpages must be
built with mandb. This is what this commits does.
A similar change was done for NixOS:
edc6a76cc0
Running `zplug install` will always product output, even if there is
nothing to do.
Gating it behind a `zplug check` eliminates that output when there is
nothing to do, and is recommended in the zplug README.
Adds a new `keybindings` option to the `vscode` configuration.
It contains a list of key bindings, which will be written to
`%vscode-dir%/User/keybindings.json`.
PR #1351
The previous implementation would allow variables to sneak into the
file names. This commit makes sure the resulting target file path
exactly matches the expected path.
No flake.lock is added because the only input (nixpkgs) will almost
always be overridden, and currently Home Manager's testing and
verification is not flake based.
PR #1455
This removes the dependency on the `nixpkgs` channel within the
modules for state version ≥ 20.09. The default Nixpkgs source starting
from this state version is the path of the `pkgs` argument used to
bootstrap the Home Manager modeuls.
This is a prerequisite for using Home Manager withing Nix flakes.
PR #1420
Before the profile commands would not run if a single package is
installed since `buildEnv` will produce a symlink directly to that
package. By adding this dummy package we ensure that a real directory
will be generated.
Fixes#1392
The kakoune editor has a plugin mechanism and several plugins are
already packaged under `pkgs.kakounePlugins`. However, adding these
packages to `home.packages` is not enough: the `kakoune` package needs
to be configured with the list of plugins to include, so that they get
sourced on start-up.
We add a `programs.kakoune.plugins` option, analogous to
`programs.vim.plugins`.
The change is backwards compatible since `pkgs.kakoune` is defined as
wrapKakoune kakoune-unwrapped { };
and `wrapKakoune` defaults the list of plugins to empty.
PR #1356
The git-send-email [0] script uses StartTLS if `smtpEncryption` is set
to `tls`, which can break services that don't support StartTLS.
[0]: bd42bbe1a4/git-send-email.perl (L1533)
PR #1395
Before this change,
```rust
fn main() {
println!("{:?}", glib::get_user_special_dir(glib::UserDirectory::Documents));
}
```
would return `None` even though `~/Documents` is available and
`xdg.userDirs.enable = true`. Checking the differences between
`xdg-user-dirs-update` shows that the latter has quotes around each
thing.
PR #1440
We were passing the separators for the `show-whitespaces` highlighter
verbatim. This was problematic in case one wanted to use, spaces,
quotes or `%` as separators since the resulting kakoune configuration
would be invalid.
According to kakoune's docs, the separator has to be one character
long, so we can use a simple rule for escaping them. It is possible
that people has been working this around by passing, e.g. `"' '"` as
separator in order to get a space (i.e., escaped explicitly by the
user), so we just let longer strings be used verbatim.
PR #1357
Instead of using several regex assertions, just state precisely what we
are producing. While the regex was technically more flexible, since it
would ignore differences in whitespace, it was also harder to read/edit.
This makes the systemd module use the sd-switch application to perform
the unit switch during a generation activation.
Since the closure of sd-switch is relatively lightweight we
unconditionally pull it in as a dependency. We simultaneously remove
the `systemd.user.startServices` option and perform the switch action
automatically.
PR #1388
The previous fish integration for starship erroneously used parts of
POSIX-esque test syntax. It also used `-n` instead of `-z` to check
for an unset variable.
PR #1422
This test started failing as described in the code comment. May be
related to Nixpkgs updating Fontconfig from version 2.12 to 2.13. See
https://github.com/NixOS/nixpkgs/pull/73795.
When running the service start script with `DISPLAY` set, a `gi`
import error is triggered. Blanking the variable will make the script
use a different code path that does not attempt to import `gi`.
Also moves activation script up into start of script instead.
PR #1415
The option to remove the default keybindings by setting the
`programs.qutebrowser.enableDefaultKeybindings` variable to `false`
had a list wrapped around the `config.py` line. This would cause a
type coercion error.
PR #1410
This option can be used to enable optional Spotifyd features, such as
looking up the Spotify password in the system keyring or enabling
MPRIS support.
PR #1390
Before the profile directory value would point directly to the build
output in the Nix store. Unfortunately this would cause an infinite
loop if the user's configuration directly or indirectly refers to the
profile directory value.
Fixes#1188
It is insufficient to install the packages in `home.packages`, it has
to be `home.path`, which includes configured extra package outputs or
profile commands.
Emacs populates 'exec-path' at launch from the 'PATH' environment
variable. Likewise, the emacs derivation from nixpkgs populates
'load-path' from the 'NIX_PROFILES' variable. As neither of these are
available by default in the systemd user manager, revert to the
previous behavior of launching the Emacs daemon from a login shell.
Fixes#1354Fixes#1340
PR #1355
Add 'services.emacs.socketActivation.enable' for generating an
'emacs.socket' systemd unit.
Emacs since version 26 has supported socket activation, whereby an
external process manager such as systemd listens on a socket and passes
it to the Emacs daemon when the manager launches it. This improves
startup time of the user session and avoids launching the daemon when not
needed, for example when launching the user session via SSH.
This implementation hard-codes the socket path to the default for the
version of 'programs.emacs.finalPackage', because systemd does not
perform shell expansion in the socket unit's 'ListenStream' parameter
and it seems like an advanced use-case to change the socket path. Shell
expansion would be desirable as the socket path usually resides in
directories such as $XDG_RUNTIME_DIR or $TMPDIR.
Tests were added to verify behavior in the following cases:
- Emacs service with socket activation disabled
- Emacs 26 with socket activation enabled
- Emacs 27 with socket activation enabled
PR #1314
This change stops update-mime-database from running unless the
`share/mime/packages` directory is writable. For some reason it
appears to be read-only on WSL1.
Fixes#1192
This adds a section in the documentation for describing a list of
guidelines that code in Home Manager should follow.
This also updates the pull request template to reference this new
section.
This makes it possible to refer to the path of Home Manager when you
just have a Nix expression, not the actual source. Some things run
import on a source and just give access to the result of the import,
not the source.
PR #1259
This adds an empty `nix-build` command to verify that the user is
having a good Nix install. It also, as a side effect, will create the
necessary per-user `profiles` and `gcroots` directories.
Fixes#1246
Using the `nix-env` command is far more robust. It also has the
benefit that if the per-user `profiles` and `gcroots` directories do
not exist then they will be created with the correct permissions.
Because of the second point this commit also removes the `mkdir` step
of the installation instructions.
PR #1239Closes#474, #948, #1091
Add an option to enable a .desktop file for the Emacs client.
PR #1223
Co-authored-by: Michael Lingelbach <m.j.lbach@gmail.com>
Co-authored-by: Robert Helgesson <robert@rycee.net>
Using this function it is possible to make `home.file` create a
symlink to a path outside the Nix store. For example, a Home Manager
configuration containing
home.file."foo".source = config.lib.file.mkOutOfStoreSymlink ./bar;
would upon activation create a symlink `~/foo` that points to the
absolute path of the `bar` file relative the configuration file.
PR #1211
Before the XDG variables would be set from the user's environment, if
available. This would break some tests.
With this change the tests should be fully deterministic.
Fixes#1190
Otherwise, the pager (typically `less`) pauses execution of
`home-manager switch` until the pager is dismissed, if the content is
larger than would fit on the screen.
PR #1175
This option used to make the `home-manager` command use the `nix` tool
from Nix 2. Unfortunately the `nix` tool is a bit experimental and it
is best to await its stabilization before supporting it in Home
Manager.
This switches the type of `matchBlocks` from `loaOf` to `listOrDagOf`.
The former has been deprecated in Nixpkgs. The latter allows
dependencies between entries to be expressed using the DAG functions.
Specifically, trigger NUR updates for all release branches by default.
Also updates the GitLab CI definition to use the new `rules` attribute
rather than the deprecated `only` attribute.
Add a new 'bookmarks' option, for managing `~/.config/gtk3/bookmarks`,
a list of URIs to display as bookmarks in the sidebar of GTK file
browsers.
PR #1129
It can be useful to simply instantiate a Home Manager configuration
without actually building it, for example for the purpose of
pre-building it with some custom command.
PR #1099
Nixpkgs no longer packages compton, and instead packages picom, a
(mostly) compatible fork of compton, providing an alias from compton
to picom. Because some configuration options have been changed, and
all references to "compton" have been made deprecated and replaced
with "picom", 'services.compton' has been deprecated in favor of the
new 'services.picom'.
Resolves#878
PR #1101
- Pass arguments verbatim to the `systemctl` subprocess, obviating the
need for shell escaping.
- Use open3 for capturing subprocess output.
- Fix printing of commands during dry run.
- Simplify `X-RestartIfChanged` regular expression.
1. Use \s to match whitespace, \b to match a word boundary.
2. Rename variable to conform to Ruby's underscore naming
conventions.
- Remove no-op set operation. Specifically, 'no_restart' and 'to_stop'
are disjunct since
1. After reloading the daemon with the new generation, units in
'to_stop' (i.e. units from the old gen that are missing in the
new gen) are not registered anymore in the systemd daemon.
2. Hence, 'systemctl cat' returns no output for these units.
3. Because this output is needed to detect 'no_restart' units,
'no_restart' includes no units from 'to_stop'.
So 'to_stop -= to_restart' is a no-op.
- Only notify about units that would otherwise be restarted. That is,
exclude units that are started but not restarted.
- Previously, all inactive units, like short-running services, were
handled as failed units.
Now systemd activation doesn't fail for oneshot services like
'setxkbmap' while 'servicesStartTimeoutMs' is set.
- Don't start unchanged oneshot services.
PR #1110
Enabling this flag for a `home.file` entry causes the target to be
unconditionally overwritten. The option is not visible in
documentation for now and shouldn't be relied on for general use.
Add 'services.lieer', which generates systemd timer and service units
to synchronize a Gmail account with lieer. Per-account configuration
lives in 'accounts.email.accounts.<name>.lieer.sync'.
Add 'programs.lieer', a tool for synchronizing a Gmail account with a
local maildir and notmuch database. Per-account configuration lives in
'accounts.email.accounts.<name>.lieer'.
This allows the ability to provide arguments to a function, such as
`--on-event` in order to trigger a function on the
`fish_command_not_found` event, for example.
PR #1063
When setting values using the `git config --set` command, git formats
the file a bit differently. This changes the output so it maps to that
format.
Differences:
* each `key = value` in a section is prefixed by a tab character
* the `=` between the key and the value is surrounded by spaces
PR #1069
Unfortunately the document generator is not smart enough to quote the
`..` alias in the documentation which is very misleading. By making it
a literal example the quotes stay.
Presently, if you pass an argument with spaces in it to `doBuildAttr`,
it will be split it into multiple arguments to `nix build` or
`nix-build`. This situation arises, for example, on systems with
spaces in `XDG_DATA_HOME`.
Specifically, the `home-manager` script errors out in trying to
address the `read-news` state file. With this change, argument
separation should be preserved properly in `doBuildAttr`.
PR #1044
- If a function is defined, check that the function file exists and
that the contents matches a given string.
- If no functions exists, the functions folder should not exist.
- Verify plugin functionality.
This change allows the entire repo to be imported directly. Some plugins (such
as oh-my-fish's vi-mode) have extra files that are referenced by the plugin
itself. This means we cannot create a generic plugin file structure out of the
plugins that exist currently.
The section headers help show where each section came from when looking at the
generated config. Added a note about how the config was generated in the
generated file.
This resolves the error
The option `accounts.email.accounts.xyz.neomutt.sendMailCommand`
is defined both null and not null, in
`…/home-manager/modules/accounts/email.nix' and
`…/home-manager/modules/accounts/email.nix'.
that would occur previously when both neomutt and msmtp were enabled
for an account.
This forces the `home.file` option to be completely empty when
switching to the uninstall configuration. This is necessary to guard
against files are added by default in Home Manager, such as
`$XDG_CACHE_HOME/.keep`.
The format script can be used to automatically format the Nix source
files and also verify that the files are formatted using the `-c`
command argument.
At the moment some files are exempt from the formatting to avoid
causing merge conflicts in active pull requests.
Finally, update the contribution guidelines to note that `nixfmt`
should be used.
This adds a service module for [grobi](https://github.com/fd0/grobi),
which can be used to automatically configure monitors/outputs for Xorg
via RANDR.
This allows pkgs to be overridden in such a way that `<nixpkgs>` is
never imported, allowing home-manager to be used in environments where
`NIX_PATH` is not set.
PR #993
This change makes use of the `extend` function inside `lib` to inject
a new `hm` field containing the Home Manager library functions. This
simplifies use of the Home Manager library in the modules and reduces
the risk of accidental infinite recursion.
PR #994
Given an inner type, the former function generates a type that expect
DAG option values. The latter function is only present to temporarily
allow the `programs.ssh.matchBlocks` to keep accepting list values.
In particular, this entry notes that assigning lists to `home.file`,
`xdg.configFile`, and `xdg.dataFile` is deprecated and will be removed
in the next release.
The `programs.neovim.configure` option is consistent with NixOS's
`wrapNeovim` and offers features not supported by the `extraConfig`
and `plugins` option pair.
Closes#971
This sets the state version in recent installs to the latest released
version. It is beneficial for people to be aware of this option and it
is also good to help new users get a more recent setup.
The old method for hiding the error no longer works in NixOS 19.09,
and ends up breaking blueman-applet entirely. Enable the NixOS service
instead.
Pull request #950
On NixOS it is necessary to set `bgSupport = true` when creating a
Home Manager desktop manager session. Otherwise NixOS will add code
that sets the background, overriding the effort made by the
`random-background` module.
Fixes#955
Pull request #956
In the case where `/nix` is a link, for example, on macOS Catalina,
`builtins.storeDir` returns `/nix`, not the canonical location.
This causes tests on existing files to result in Home Manager thinking
those files are outside of the store.
This change uses `readlink` on the store path so that the tests work
as intended.
The Astroid program can work without this option,
which should be disabled when synchronising emails with muchsync for example.
This reverts commit fa3d1f98e0.
- Default value is set to static '$HOME/.zsh_history' -- dotDir is not
prepended anymore
- $HOME is not prepended to the option value
- Ensure history path directory exists
Fixes#886, replaces #427.
This replaces some derivation outputs by simple strings rather than
full Nix store paths. This removes the need to download the whole
derivation when all we need is a static string.
This allows specifying, for example, the music directory using path
literals without causing the directory to be copied to the Nix store.
Suggested-by: Silvan Mosberger <infinisil@icloud.com>
The [throw-keyids](https://www.gnupg.org/gph/en/manual/r2110.html)
option "hides the receiver of the encrypted data as a countermeasure
against traffic analysis." However, it also slows down decryption, and
even breaks some applications; see e.g.
https://github.com/open-keychain/open-keychain/issues/626
I think the sane default would be to leave it off, just as it is off
by default in gpg. The typical user will probably not need this level
of security, and will probably prefer a better user experience (faster
decryption and compatibility with a wider range of applications).
Closes#838
MPD is using syslog for its logging output, while it could directly
log to systemd's journal, as this daemon is primarily used as a
systemd user service. This change makes MPD log to standard output,
which is captured by systemd.
See https://github.com/NixOS/nixpkgs/pull/57608, which does the same
thing to NixOS's MPD service.
This change allows to pass custom packages into the `vim.plugins`
option.
Additionally this adds a deprecation warning and an error message if a
vim plugin is not present. This is an improvement because the user
gets instant feedback, when a plugin is not found.
This makes the
programs.firefox.package
option take a pre-wrapped Firefox package as value if state version is
set to "19.09" or later. This should make the Firefox module work with
a wider range of Firefox packages.
This commit adds a "build" command to the install derivation that
tells the user that `nix-shell` should be used.
A derivation attribute `shellHookOnly = true` is also added with the
intent to indicate that the shell hook is the entire point of the
derivation.
enableCompletion option not only calls compinit but also adds
nix-zsh-completions package to home.packages which should still happen
even if oh-my-zsh is enabled.
The double compinit call will still be eliminated by moving guarding condition
down to the compinit call itself.
Fixes#771.
This patch started by addresssing the code review comments to close
https://github.com/rycee/home-manager/pull/290. However initiating a new
pull request it became clear, that home-manager changed significantly
since then.
This changes the initial pull request to be consistent with the email
account management in home-manager now. It also adds a simple test and support
for multiple accounts.
Because `extraPackages` and `overrides` expect functions as values it
has not been possible to perform merges. This adds suitable types for
these options that allow reasonable merging.
This rewrite allows "long options" but unfortunately does not allow
merged options such as `-vn`.
Also improve the home-manager manual page, with this it should include
all sub-commands and arguments.
Finally, include the home-manager manual page in the generated HTML
documentation.
When a configuration file would be written to an existing file, rather
than failing switch (and having the user have to move or delete those
files), move the files automatically to a new path.
Closes#585
In particular, don't add trailing backslashes introduced by
`xautolockExtraOptions`. Systemd's unit file parser seems to have
gotten a bit stricter and with systemd 242, the trailing backslash
caused the next non-empty line to be ignored.
In that case, this was `[Section]`, so all subsequent settings were
mistakenly added to `[Service]`, causing them to be ignored entirely.
Simplify and fix this by using `concatStringsSep` to build a single
`ExecStart` line.
This fixes a build error occurring when building a configuration
having fontconfig enabled and `home.packages` only containing one
package installing things to `/lib`.
Also adds a number of test cases to verify the fontconfig cache
generation functionality.
Fixes#703
Add parens to expression so the `-exec` includes files matching both.
Otherwise (before this change) the `-exec` is only invoked for
links (`-type l`):
file or (link -> doexec)
=>
(file or link) -> doexec
Also deprecates the `fonts.fontconfig.enableProfileFonts` option. The
configuration is now always generated if `fonts.fontconfig.enable` is
set.
Fixes#520
Unfortunately, using `attrsOf` is not possible since it results in too
eager evaluation. In particular, the
home.sessionVariables = {
FOO = "Hello";
BAR = "${config.home.sessionVariables.FOO} World!";
};
example will cause an infinite recursion.
This commit restores the option type of
- `home.sessionVariables`,
- `pam.sessionVariables`,
- `programs.bash.sessionVariables`, and
- `programs.zsh.sessionVariables`
to `attrs`. It also adds test cases for the above options to avoid
regressions.
Fixes#659
Having this in the unit file will prevent the file from being
restarted if a change is detected. This is useful if data loss may
occur if the unit is suddenly restarted. For example, restarting the
Emacs service may result in the loss of unsaved open buffers.
This should allow more sensible merging behavior. In particular, with
this change it is possible to use, for example, `mkForce` for greater
control of merging.
Fixes#543
When using the NixOS module we cannot guarantee that the Nix store
will be writable during startup. Installing the user packages through
`nix-env -i` will fail in these cases.
This commit adds a NixOS option `home-manager.useUserPackages` that,
when enabled, installs user packages through the NixOS
users.users.<name?>.packages
option.
Note, when submodule support and external package install is enabled
then the installed packages are not available in `~/.nix-profile`. We
therefore set `home.profileDirectory` directly to the HM profile
packages.
This removes the `nixosSubmodule` option in favor of a new option
`submoduleSupport.enable`. This name better indicates that the
submodule mode applies to both NixOS and nix-darwin.
On non-x86 architectures (for example, aarch64) the installation of
home-manager fails indicating that it is attempting to select i686
packages for Linux and those aren't available.
Solution: make the condition for choosing these packages stricter
Makes fish use global scope for abbreviations.
This makes it so that they don't stick across config changes.
Before, an abbreviation would still exist even if removed from the config.
In particular support source files whose name start with `.` or
contain characters not allowed in the nix store, such as spaces.
Also add some test cases for `home.file`.
This patch allow to define custom msmtp options per email account. For
example: to change the "auth" method from "on" to "login", add
`msmtp.extraConfig.auth="login"`.
Add option "extraLocalVars" for additional local variable definitions
in .zshrc, at the top of the file.
Some zsh plugins/themes expect configuration in local variables before they
are loaded (example: https://github.com/bhilburn/powerlevel9k). Exporting
those clutters the environment and is unnecessary.
Use the new module lib.zsh to generate export statements in zsh syntax, using
zsh arrays for lists.
Being a zsh script, this seems more intuitive for .zshrc
Added utilities to generate export statements and definitions for zsh scripts.
Currently, there is only lib.shell which generates export statements in bash
syntax. However, this does not allow to generate export statements for zsh
arrays (syntax: NAME=(elem1 elem2 ...) ), which would be the natural
representation of lists in the nix language.
All default keybindings should have a default priority attached to them.
This will allow users to redefine some of the default keybindings
without using mkForce. Fixes#485.
With this change, running
home-manager edit
opens `$HOME_MANAGER_CONFIG` in `$EDITOR`.
This is mainly for convenience. Users should not have to remember the
exact location of the Home Manager configuration.
This avoids the uncontrollable nature of fetching the tarball as part
of the evaluation. Instead the user can decide when to update and also
perform rollbacks, if necessary.
Instead of using the hostname `%h`, which can be changed by the
~/.ssh/config file, use the commandline-given hostname `%n`.
This allows to alias a host with different hostnames, which then point
to different configurations. A common use-case for this is if you have
multiple accounts on github with each access to different private repos:
Host github.com
IdentitiesOnly yes
User git
IdentityFile ~/.ssh/id_rsa
Host customer.github.com
IdentitiesOnly yes
User git
IdentityFile ~/.ssh/customer
HostName github.com
Without this change, if a connection was established with the first
github.com alias, then the user would try to pull a repo from the second
account, ssh would re-use the SSH connection which doesn't have access
to that repository.
This commit adds the tmux program to Home Manager.
In addition to configuring tmux, a user may specify tmux plugins from
Nixpkgs. These can be included in the list of `plugins` and can either
be a package (all tmux plugins live under `nixpkgs.tmuxPlugins.*`), or
an object which includes the plugin and an `extraConfig`, which will
be run immediately after sourcing the tmux plugin.
Finally, this commit introduces two nested programs which may be
enabled which depend on tmux: tmuxp and tmuxinator. These do not have
the ability to be configured, although this may be a future
contribution.
This reverts the commits
- "alot: change msmtp default command"
8e798e4c28
- "astroid: init"
736e340bde
because they include changes that break some configurations and some
options that are misplaced.
The current documentation does not provide guidance to users on how
systemd units are defined in Home Manager. A user may expect the
configuration to be similar to NixOS, when it actually differs.
Fixes#418
This adds a new command to the home-manager shell script that allows
generations to be removed that are older than an given absolute or
relative date.
This allows users to manage the expiration of their home-manager
generations separately from their system or user profiles via
nix-collect-garbage. It is most important if the user desires to have
a convenient way to have different expiration times for Home Manager
generations than other system or user profiles.
The ExecStartPost command is currently started when the mbsync is
invoked succesfully. However, we typically want to run something like
'mu index' or 'notmuch new' after mbsync completes. This changes the
unit type to oneshot, so that the ExecStartPost command is run after
mbsync finishes succesfully.
To allow supporting more advanced configurations. The local refers to
the "maildir store" configuration, remote to the "IMAP store", and
"channel" to the channel.
This option allows overriding the default script path `~/.xsession`.
On NixOS, this is needed to allow multiple possible graphical login
sessions.
Fixes#391.
This allows you to specify your own custom commands
to be run when calling fzf. You might use tools like
fd to search faster and take `.gitignore` files into
consideration.
This reverts commit d5bbbbd41d.
This was premature, the example will not emit a terminal newline and
it is not clear whether it is a good idea to force this limitation.
This reworks the way program specific email account options are
specified. In particular, we no longer use the deprecated `options`
field of `mkOption`. Instead submodules are used.
In particular, don't bother attempting to do substitution of the home
files and home generation derivations since these rarely, if ever,
could be substituted.
Fixes#330
It was previously possible to create the news information and lose it
in a Nix GC before being able to view it. This also causes a switch to
error out. This change makes the news information a root in the
garbage collector.
Note, this change also removes the need for `nix eval` so the
`doBuildAttr` function is simplified accordingly.
Fixes#327
Home Manager needs an absolute and resolved path to its configuration
file. The default configuration path is absolute but not necessarily
resolved. For example, some users may have `~/.config` be a symbolic
link to somewhere else. We therefore run the default configuration
path through the `realpath` tool to resolve it.
Fixes#304
This adds an experimantal, undocumented, and unsupported flag `-2` for
the `home-manager` command that enables the use of the new `nix`
command instead of `nix-build`.
This adds a general module infrastructure for configuring email
accounts. The intent is to specify high level information such as IMAP
and SMTP hostnames and login information so that more specific program
and service modules do not have to duplicate options for specifying
accounts.
It is allowed for modules to inject further options within this
namespace where relevant. For example, an MUA may wish add an option
to add per-account filter rules.
Co-authored-by: Matthieu Coudron <mattator@gmail.com>
By default, i3-msg gets socket from X11 property
which is not available when home manager is running
as nixos module.
This patch changes i3-msg command call by specifying
all i3 sockets found in $XDG_RUNTIME_DIR/i3 folder.
Fixes#252.
This removes the need for monolithic unit definitions and allows
users to modify existing units.
Example:
```
{
systemd.user.services.owncloud-client.Unit.OnFailure = "my-notify-service";
}
```
Unfortunately this duplicates some code from NixOS but it does allow
much more flexibility and, hopefully, stability in the Home Manager
documentation.
Fixes#254.
This is needed to support overriding these options inside match
blocks. A new option `programs.ssh.extraOptionOverrides` has been
added to allow global overrides.
This option enables a GPG Agent restricted socket (aka "extra-socket"), which
can be used to forward GPG Agent over SSH.
Additionally `verbose` option enables verbose output of an `gpg-agent.service`
unit for easier debugging.
See: https://wiki.gnupg.org/AgentForwarding
It is safest to use the system install of Nix since that will be
compatible with the running nix-daemon and/or databases.
Also add a printout of the used Nix version in the activation script
when running in verbose mode.
Fixes#218.
Curiously the `who` command sometimes does not list logged-in users,
resulting in systemd not being reloaded. Instead we use
systemctl --user is-system-running
to more directly detect whether systemd is running.
The preferred method of theming rofi is now to use "rasi" theme files.
This commit therefore downplays the colors option and introduces the
theme option.
2018-02-10 20:11:33 +01:00
1313 changed files with 77932 additions and 4773 deletions
- [ ] Code tested through `nix-shell --pure tests -A run.all` or `nix develop --ignore-environment .#all` using Flakes.
- [ ] Test cases updated/added. See [example](https://github.com/nix-community/home-manager/commit/f3fbb50b68df20da47f9b0def5607857fcc0d021#diff-b61a6d542f9036550ba9c401c80f00ef).
- [ ] Commit messages are formatted like
```
{component}: {description}
{long description}
```
See [CONTRIBUTING](https://github.com/nix-community/home-manager/blob/master/docs/contributing.adoc#sec-commit-style) for more information and [recent commit messages](https://github.com/nix-community/home-manager/commits/master) for examples.
- If this PR adds a new module
- [ ] Added myself as module maintainer. See [example](https://github.com/nix-community/home-manager/blob/068ff76a10e95820f886ac46957edcff4e44621d/modules/programs/lesspipe.nix#L6).
# Configuration for probot-stale - https://github.com/probot/stale
daysUntilStale:90
daysUntilClose:false
staleLabel:"status: stale"
issues:
markComment:|
<p>
Thank you for your contribution!
I marked this issue as stale due to inactivity.
Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'.
We welcome additional information that will help resolve this issue.
<b>Please read the relevant sections below before commenting.</b>
</p>
<details>
<summary><b>If you are the original author of the issue</b></summary>
<p>
* If this is resolved, please consider closing it so that the maintainers know not to focus on this.
* If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
* If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.
</p>
</details>
<details>
<summary><b>If you are <i>not</i> the original author of the issue</b></summary>
<p>
* If you are also experiencing this issue, please add details of your situation to help with the debugging process.
* If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.
</p>
</details>
<details>
<summary><b>Memorandum on closing issues</b></summary>
<p>
Don't be afraid to manually close an issue, even if it holds valuable information.
Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost!
Closing obsolete issues is an important way to help maintainers focus their time and effort.
</p>
</details>
pulls:
markComment:|
<p>
Thank you for your contribution!
I marked this pull request as stale due to inactivity.
<b>Please read the relevant sections below before commenting.</b>
</p>
<details>
<summary><b>If you are the original author of the PR</b></summary>
<p>
* GitHub sometimes doesn't notify people who commented / reviewed a PR previously when you (force) push commits. *If you have addressed the reviews* you can [officially ask for a review](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/requesting-a-pull-request-review) from those who commented to you or anyone else.
* If it is unfinished but you plan to finish it, please mark it as a draft.
* If you don't expect to work on it any time soon, please consider closing it with a short comment encouraging someone else to pick up your work.
* To get things rolling again, rebase the PR against the target branch and address valid comments.
</p>
</details>
<details>
<summary><b>If you are <i>not</i> the original author of the PR</b></summary>
<p>
* If you want to pick up the work on this PR, please create a new PR and indicate that it supercedes and closes this PR.
building path(s) ‘/nix/store/b5c0asjz9f06l52l9812w6k39ifr49jj-user-environment’
Wide character in die at /nix/store/64jc9gd2rkbgdb4yjx3nrgc91bpjj5ky-buildenv.pl line 79.
collision between ‘/nix/store/fmwa4axzghz11cnln5absh31nbhs9lq1-home-manager-path/bin/hello’ and ‘/nix/store/c2wyl8b9p4afivpcz8jplc9kis8rj36d-hello-2.10/bin/hello’; use ‘nix-env --set-flag priority NUMBER PKGNAME’ to change the priority of one of the conflicting packages
builder for ‘/nix/store/b37x3s7pzxbasfqhaca5dqbf3pjjw0ip-user-environment.drv’ failed with exit code 2
error: build of ‘/nix/store/b37x3s7pzxbasfqhaca5dqbf3pjjw0ip-user-environment.drv’ failed
```
The solution is typically to uninstall the package from the
environment using `nix-env--uninstall` and reattempt the Home Manager
generation switch.
Why are the session variables not set?
--------------------------------------
Home Manager is only able to set session variables automatically if it
manages your Bash or Z shell configuration. If you don't want to let
Home Manager manage your shell then you will have to manually source
the
~/.nix-profile/etc/profile.d/hm-session-vars.sh
file in an appropriate way. In Bash and Z shell this can be done by
Contributions to Home Manager are very welcome. To make the process as smooth as possible for both you and the Home Manager maintainers we provide some guidelines that we ask you to follow. See <<sec-contrib-getting-started>> for information on how to set up a suitable development environment and <<sec-guidelines>> for the actual guidelines.
This text is mainly directed at those who would like to make code contributions to Home Manager. If you just want to report a bug then first look among the already {open-issues}[open issues], if you find one matching yours then feel free to comment on it to add any additional information you may have. If no matching issue exists then go to the {new-issue}[new issue] page and write a description of your problem. Include as much information as you can, ideally also include relevant excerpts from your Home Manager configuration.
[[sec-contrib-getting-started]]
=== Getting started
If you have not previously forked Home Manager then you need to do that first. Have a look at GitHub's {fork-a-repo}[Fork a repo] for instructions on how to do this.
Once you have a fork of Home Manager you should create a branch starting at the most recent `master` branch. Give your branch a reasonably descriptive name. Commit your changes to this branch and when you are happy with the result and it fulfills <<sec-guidelines>> then push the branch to GitHub and {create-a-pull-request}[create a pull request].
Assuming your clone is at `$HOME/devel/home-manager` then you can make the `home-manager` command use it by either
1. overriding the default path by using the `-I` command line option:
If your contribution satisfy the following rules then there is a good chance it will be merged without too much trouble. The rules are enforced by the Home Manager maintainers and to a lesser extent the Home Manager CI system.
If you are uncertain how these rules affect the change you would like to make then feel free to start a discussion in the {irc-home-manager}[#home-manager] IRC channel, ideally before you start developing.
[[sec-guidelines-back-compat]]
==== Maintain backward compatibility
Your contribution should not cause another user's existing configuration to break unless there is a very good reason and the change should be announced to the user through an {assertions}[assertion] or similar.
Remember that Home Manager is used in many different environments and you should consider how your change may effect others. For example,
- Does your change work for people that do not use NixOS? Consider other GNU/Linux distributions and macOS.
- Does your change work for people whose configuration is built on one system and deployed on another system?
[[sec-guidelines-forward-compat]]
==== Keep forward compatibility in mind
The master branch of Home Manager tracks the unstable channel of Nixpkgs, which may update package versions at any time. It is therefore important to consider how a package update may affect your code and try to reduce the risk of breakage.
The most effective way to reduce this risk is to follow the advice in <<sec-guidelines-valuable-options>>.
[[sec-guidelines-valuable-options]]
==== Add only valuable options
When creating a new module it is tempting to include every option supported by the software. This is _strongly_ discouraged. Providing many options increases maintenance burden and risk of breakage considerably. This is why only the most {valuable-options}[important software options] should be modeled explicitly. Less important options should be expressible through an `extraConfig` escape hatch.
A good rule of thumb for the first implementation of a module is to only add explicit options for those settings that absolutely must be set for the software to function correctly. It follows that a module for software that provides sensible default values for all settings would require no explicit options at all.
If the software uses a structured configuration format like a JSON, YAML, INI, TOML, or even a plain list of key/value pairs then consider using a `settings` option as described in {rfc-42}[Nix RFC 42].
[[sec-guidelines-add-tests]]
==== Add relevant tests
If at all possible, make sure to add new tests and expand existing tests so that your change will keep working in the future. See <<sec-tests>> for more information about the Home Manager test suite.
Many code changes require changing the documentation as well. Module options should be documented with DocBook. See {docbook-rocks}[DocBook rocks!] for a quick introduction and {docbook}[DocBook 5: The Definitive Guide] for in-depth information of DocBook. Home Manager is itself documented using a combination of DocBook and {asciidoc}[AsciiDoc]. All text is hosted in Home Manager's Git repository.
The HTML version of the manual containing both the module option descriptions and the documentation of Home Manager can be generated and opened by typing the following in a shell within a clone of the Home Manager Git repository:
When you have made changes to a module, it is a good idea to check that the man page version of the module options looks good:
[source,console]
$ nix-build -A docs.manPages
$ man ./result/share/man/man5/home-configuration.nix.5.gz
==== Add yourself as a module maintainer
Every new module _must_ include a named maintainer using the `meta.maintainers` attribute. If you are a user of a module that currently lacks a maintainer then please consider adopting it.
If you are present in the nixpkgs maintainer list then you can use that entry. If you are not then you can add yourself to `modules/lib/maintainers.nix` in the Home Manager project.
Maintainers are encouraged to join the IRC or Matrix channel and participate when they have opportunity.
[[sec-guidelines-code-style]]
==== Format your code
Make sure your code is formatted as described in <<sec-code-style>>. To maintain consistency throughout the project you are encouraged to browse through existing code and adopt its style also in new code.
[[sec-guidelines-commit-message-style]]
==== Format your commit messages
Similar to <<sec-guidelines-code-style>> we encourage a consistent commit message format as described in <<sec-commit-style>>.
[[sec-guidelines-news-style]]
==== Format your news entries
If your contribution includes a change that should be communicated to users of Home Manager then you can add a news entry. The entry must be formatted as described in <<sec-news>>.
When new modules are added a news entry should be included but you do not need to create this entry manually. The merging maintainer will create the entry for you. This is to reduce the risk of merge conflicts.
[[sec-guidelines-conditional-modules]]
==== Use conditional modules and news
Home Manager includes a number of modules that are only usable on some of the supported platforms. The most common example of platform specific modules are those that define systemd user services, which only works on Linux systems.
If you add a module that is platform specific then make sure to include a condition in the `loadModule` function call. This will make the module accessible only on systems where the condition evaluates to `true`.
Similarly, if you are adding a news entry then it should be shown only to users that may find it relevant, see <<sec-news>> for a description of conditional news.
[[sec-guidelines-licensing]]
==== Mind the license
The Home Manager project is covered by the MIT license and we can only accept contributions that fall under this license, or are licensed in a compatible way. When you contribute self written code and documentation it is assumed that you are doing so under the MIT license.
A potential gotcha with respect to licensing are option descriptions. Often it is convenient to copy from the upstream software documentation. When this is done it is important to verify that the license of the upstream documentation allows redistribution under the terms of the MIT license.
[[sec-commit-style]]
=== Commits
The commits in your pull request should be reasonably self-contained, that is, each commit should make sense in isolation. In particular, you will be asked to amend any commit that introduces syntax errors or similar problems even if they are fixed in a later commit.
The commit messages should follow the {seven-rules}[seven rules], except for "Capitalize the subject line". We also ask you to include the affected code component or module in the first line. That is, a commit message should follow the template
----
{component}: {description}
{long description}
----
where `{component}` refers to the code component (or module) your change affects, `{description}` is a very brief description of your change, and `{long description}` is an optional clarifying description. As a rare exception, if there is no clear component, or your change affects many components, then the `{component}` part is optional. See <<ex-commit-message>> for a commit message that fulfills these requirements.
Finally, when adding a new module, say `programs/foo.nix`, we use the fixed commit format `foo: add module`. You can, of course, still include a long description if you wish.
[[sec-code-style]]
=== Code Style
The code in Home Manager is formatted by the {nixfmt}[nixfmt] tool and the formatting is checked in the pull request tests. Run the `format` tool inside the project repository before submitting your pull request.
Keep lines at a reasonable width, ideally 80 characters or less. This also applies to string literals.
We prefer `lowerCamelCase` for variable and attribute names with the accepted exception of variables directly referencing packages in Nixpkgs which use a hyphenated style. For example, the Home Manager option `services.gpg-agent.enableSshSupport` references the `gpg-agent` package in Nixpkgs.
[[sec-news]]
=== News
Home Manager includes a system for presenting news to the user. When making a change you, therefore, have the option to also include an associated news entry. In general, a news entry should only be added for truly noteworthy news. For example, a bug fix or new option does generally not need a news entry.
If you do have a change worthy of a news entry then please add one in {news-nix}[`news.nix`] but you should follow some basic guidelines:
- The entry timestamp should be in ISO-8601 format having "+00:00" as time zone. For example, "2017-09-13T17:10:14+00:00". A suitable timestamp can be produced by the command
+
[source,console]
$ date --iso-8601=second --universal
- The entry condition should be as specific as possible. For example, if you are changing or deprecating a specific option then you could restrict the news to those users who actually use this option.
- Wrap the news message so that it will fit in the typical terminal, that is, at most 80 characters wide. Ideally a bit less.
- Unlike commit messages, news will be read without any connection to the Home Manager source code. It is therefore important to make the message understandable in isolation and to those who do not have knowledge of the Home Manager internals. To this end it should be written in more descriptive, prose like way.
- If you refer to an option then write its full attribute path. That is, instead of writing
+
----
The option 'foo' has been deprecated, please use 'bar' instead.
----
+
it should read
+
----
The option 'services.myservice.foo' has been deprecated, please
use 'services.myservice.bar' instead.
----
- A new module, say `foo.nix`, should always include a news entry that has a message along the lines of
+
----
A new module is available: 'services.foo'.
----
+
If the module is platform specific, e.g., a service module using systemd, then a condition like
+
[source,nix]
condition = hostPlatform.isLinux;
+
should be added. If you contribute a module then you don't need to add this entry, the merger will create an entry for you.
[[sec-tests]]
=== Tests
Home Manager includes a basic test suite and it is highly recommended to include at least one test when adding a module. Tests are typically in the form of "golden tests" where, for example, a generated configuration file is compared to a known correct file.
It is relatively easy to create tests by modeling the existing tests, found in the `tests` project directory.
The full Home Manager test suite can be run by executing
[source,console]
$ nix-shell --pure tests -A run.all
in the project root. List all test cases through
[source,console]
$ nix-shell --pure tests -A list
and run an individual test, for example `alacritty-empty-settings`, through
[source,console]
$ nix-shell --pure tests -A run.alacritty-empty-settings
However, those invocations will impurely source the system’s nixpkgs, and may cause failures. To run against the nixpkgs from the flake.lock, use instead e.g.
=== Why is there a collision error when switching generation?
Home Manager currently installs packages into the user environment, precisely as if the packages were installed through `nix-env--install`. This means that you will get a collision error if your Home Manager configuration attempts to install a package that you already have installed manually, that is, packages that shows up when you run `nix-env--query`.
For example, imagine you have the `hello` package installed in your environment
[source,console]
----
$ nix-env --query
hello-2.10
----
and your Home Manager configuration contains
[source,nix]
----
home.packages = [ pkgs.hello ];
----
Then attempting to switch to this configuration will result in an error similar to
building path(s) ‘/nix/store/b5c0asjz9f06l52l9812w6k39ifr49jj-user-environment’
Wide character in die at /nix/store/64jc9gd2rkbgdb4yjx3nrgc91bpjj5ky-buildenv.pl line 79.
collision between ‘/nix/store/fmwa4axzghz11cnln5absh31nbhs9lq1-home-manager-path/bin/hello’ and ‘/nix/store/c2wyl8b9p4afivpcz8jplc9kis8rj36d-hello-2.10/bin/hello’; use ‘nix-env --set-flag priority NUMBER PKGNAME’ to change the priority of one of the conflicting packages
builder for ‘/nix/store/b37x3s7pzxbasfqhaca5dqbf3pjjw0ip-user-environment.drv’ failed with exit code 2
error: build of ‘/nix/store/b37x3s7pzxbasfqhaca5dqbf3pjjw0ip-user-environment.drv’ failed
----
The solution is typically to uninstall the package from the environment using `nix-env--uninstall` and reattempt the Home Manager generation switch.
You could also opt to unistall _all_ of the packages from your profile with `nix-env--uninstall'*'`.
Home Manager is only able to set session variables automatically if it manages your Bash, Z shell, or fish shell configuration. To enable such management you use <<opt-programs.bash.enable>>, <<opt-programs.zsh.enable>>, or <<opt-programs.fish.enable>>.
If you don't want to let Home Manager manage your shell then you will have to manually source the `~/.nix-profile/etc/profile.d/hm-session-vars.sh` file in an appropriate way. In Bash and Z shell this can be done by adding
to your `.profile` and `.zshrc` files, respectively. The `hm-session-vars.sh` file should work in most Bourne-like shells. For fish shell, it is possible to source it using {foreign-env}[the foreign-env plugin]
A typical way to prepare a repository of configurations for multiple logins and machines is to prepare one "top-level" file for each unique combination.
For example, if you have two machines, called "kronos" and "rhea" on which you want to configure your user "jane" then you could create the files
- `kronos-jane.nix`,
- `rhea-jane.nix`, and
- `common.nix`
in your repository.
On the kronos and rhea machines you can then make
`~jane/.config/home-manager/home.nix`
be a symbolic link to the corresponding file in your configuration repository.
The `kronos-jane.nix` and `rhea-jane.nix` files follow the format
[source,nix]
----
{ ... }:
{
imports = [ ./common.nix ];
# Various options that are specific for this machine/user.
}
----
while the `common.nix` file contains configuration shared across the two logins. Of course, instead of just a single `common.nix` file you can have multiple ones, even one per program or service.
You can get some inspiration from the {post-your-homenix}[Post your home-manager home.nix file!] Reddit thread.
=== Why do I get an error message about `ca.desrt.dconf` or `dconf.service`?
You are most likely trying to configure something that uses dconf
but the DBus session is not aware of the dconf service.
The full error you might get is
----
error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name ca.desrt.dconf was not provided by any .service files
----
or
----
error: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit dconf.service not found.
----
The solution on NixOS is to add
[source,nix]
programs.dconf.enable = true;
to your system configuration.
=== How do I install packages from Nixpkgs unstable?
If you are using a stable version of Nixpkgs but would like to install some particular packages from Nixpkgs unstable – or some other channel – then you can import the unstable Nixpkgs and refer to its packages within your configuration. Something like
[source,nix]
----
{ pkgs, config, ... }:
let
pkgsUnstable = import <nixpkgs-unstable> {};
in
{
home.packages = [
pkgsUnstable.foo
];
# …
}
----
should work provided you have a Nix channel called `nixpkgs-unstable`.
You can add the `nixpkgs-unstable` channel by running
By default Home Manager will install the package provided by your chosen `nixpkgs` channel but occasionally you might end up needing to change this package. This can typically be done in two ways.
1. If the module provides a `package` option, such as `programs.beets.package`, then this is the recommended way to perform the override. For example,
The 20.09 release branch became the stable branch in late September, 2020.
[[sec-release-20.09-highlights]]
=== Highlights
This release has the following notable changes:
* Nothing has happened.
[[sec-release-20.09-state-version-changes]]
=== State Version Changes
The state version in this release includes the changes below. These
changes are only active if the `home.stateVersion` option is set to
"20.09" or later.
* The options <<opt-home.homeDirectory>> and <<opt-home.username>> no
longer have default values and must therefore be provided in your
configuration. Previously their values would default to the content of
the environment variables `HOME` and `USER`, respectively.
+
--
Further, the options <<opt-xdg.cacheHome>>, <<opt-xdg.configHome>>,
and <<opt-xdg.dataHome>> will no longer be affected by the
`XDG_CACHE_HOME`, `XDG_CONFIG_HOME`, and `XDG_DATA_HOME` environment
variables. They now unconditionally default to
- `"${config.home.homeDirectory}/.cache"`,
- `"${config.home.homeDirectory}/.config"`, and
- `"${config.home.homeDirectory}/.local/share"`.
If you choose to switch to state version 20.09 then you must set these
options if you use non-default XDG base directory paths.
The initial configuration generated by
[source,console]
$ nix-shell '<home-manager>' -A install
will automatically include these options, when necessary.
--
* Git's `smtpEncryption` option is now set to `tls` only if both <<opt-accounts.email.accounts.\_name_.smtp.tls.enable>> and <<opt-accounts.email.accounts.\_name_.smtp.tls.useStartTls>> are `true`. If only <<opt-accounts.email.accounts.\_name_.smtp.tls.enable>> is `true`, `ssl` is used instead.
* The `nixpkgs` module no longer references `<nixpkgs>`. Before it would do so when building the `pkgs` module argument. Starting with state version 20.09, the `pkgs` argument is instead built from the same Nixpkgs that was used to initialize the Home Manager modules. This is useful, for example, when using Home Manager within a Nix Flake. If you want to keep using `<nixpkgs>` with state version ≥ 20.09 then add
+
[source,nix]
_module.args.pkgsPath = <nixpkgs>;
+
to your Home Manager configuration.
* The options `wayland.windowManager.sway.config.bars` and `opt-xsession.windowManager.i3.config.bars` have been changed so that most of the suboptions are now nullable and default to `null`. The default for these two options has been changed to manually set the old defaults for each suboption. The overall effect is that if the `bars` options is not set, then the default remains the same. On the other hand, something like:
* Rofi version 1.7.0 removed many options that were used by the module and replaced them with custom themes, which are more flexible and powerful.
+
You can replicate your old configuration by moving those options to <<opt-programs.rofi.theme>>. Keep in mind that the syntax is different so you may need to do some changes.
* Taskwarrior version 2.6.0 respects XDG Specification for the config file now.
Option <<opt-programs.taskwarrior.config>> and friends now generate the config file at
`$XDG_CONFIG_HOME/task/taskrc` instead of `~/.taskrc`.
[[sec-release-21.11-state-version-changes]]
=== State Version Changes
The state version in this release includes the changes below. These
changes are only active if the `home.stateVersion` option is set to
"21.11" or later.
* The <<opt-home.keyboard>> option now defaults to `null`, meaning that Home Manager won't do any keyboard layout management. For example, `setxkbmap` won't be run in X sessions.
* The <<opt-programs.pet.settings>> option no longer place its value inside a `General` attribute.
For example,
+
[source,nix]
programs.pet.settings.editor = "nvim";
+
becomes
+
[source,nix]
programs.pet.settings.General.editor = "nvim";
* The <<opt-programs.waybar.settings>> option now allows defining modules directly under <<opt-programs.waybar.settings>>.
Your use of Home Manager is centered around the configuration file,
which is typically found at `~/.config/home-manager/home.nix` in the standard installation
or `~/.config/home-manager/flake.nix` in a Nix flake based installation.
[NOTE]
The default configuration used to be placed in `~/.config/nixpkgs`¸
so you may see references to that elsewhere.
The old directory still works but Home Manager will print a warning message when used.
This configuration file can be _built_ and _activated_.
Building a configuration produces a directory in the Nix store that contains all files and programs that should be available in your home directory and Nix user profile, respectively. The build step also checks that the configuration is valid and it will fail with an error if you, for example, assign a value to an option that does not exist or assign a value of the wrong type. Some modules also have custom assertions that perform more detailed, module specific, checks.
Concretely, if your configuration contains
[source,nix]
programs.emacs.enable = "yes";
then building it, for example using `home-manager build`, will result in an error message saying something like
[source,console]
----
$ home-manager build
error: A definition for option `programs.emacs.enable' is not of type `boolean'. Definition values:
- In `/home/jdoe/.config/home-manager/home.nix': "yes"
(use '--show-trace' to show detailed location information)
----
The message indicates that you must provide a Boolean value for this option, that is, either `true` or `false`. The documentation of each option will state the expected type, for <<opt-programs.emacs.enable>> you will see ``Type: boolean''. You there also find information about the default value and a description of the option. You can find the complete option documentation in <<ch-options>> or directly in the terminal by running
[source,console]
man home-configuration.nix
Once a configuration is successfully built, it can be activated. The activation performs the steps necessary to make the files, programs, and services available in your user environment. The `home-manager switch` command performs a combined build and activation.
[[sec-usage-configuration]]
=== Configuration Example
A fresh install of Home Manager will generate a minimal `~/.config/home-manager/home.nix` file containing something like
[source,nix]
----
{ config, pkgs, ... }:
{
# Home Manager needs a bit of information about you and the
# paths it should manage.
home.username = "jdoe";
home.homeDirectory = "/home/jdoe";
# This value determines the Home Manager release that your
# configuration is compatible with. This helps avoid breakage
# when a new Home Manager release introduces backwards
# incompatible changes.
#
# You can update Home Manager without changing this value. See
# the Home Manager release notes for a list of state version
# changes in each release.
home.stateVersion = "23.05";
# Let Home Manager install and manage itself.
programs.home-manager.enable = true;
}
----
You can use this as a base for your further configurations.
[NOTE]
If you are not very familiar with the Nix language and NixOS modules then it is encouraged to start with small and simple changes. As you learn you can gradually grow the configuration with confidence.
As an example, let us expand the initial configuration file to also install the htop and fortune packages, install Emacs with a few extra packages available, and enable the user gpg-agent service.
To satisfy the above setup we should elaborate the `home.nix` file as follows:
[source,nix]
----
{ config, pkgs, ... }:
{
# Home Manager needs a bit of information about you and the
# paths it should manage.
home.username = "jdoe";
home.homeDirectory = "/home/jdoe";
# Packages that should be installed to the user profile.
home.packages = [ <1>
pkgs.htop
pkgs.fortune
];
# This value determines the Home Manager release that your
# configuration is compatible with. This helps avoid breakage
# when a new Home Manager release introduces backwards
# incompatible changes.
#
# You can update Home Manager without changing this value. See
# the Home Manager release notes for a list of state version
# changes in each release.
home.stateVersion = "23.05";
# Let Home Manager install and manage itself.
programs.home-manager.enable = true;
programs.emacs = { <2>
enable = true;
extraPackages = epkgs: [
epkgs.nix-mode
epkgs.magit
];
};
services.gpg-agent = { <3>
enable = true;
defaultCacheTtl = 1800;
enableSshSupport = true;
};
}
----
<1> Nixpkgs packages can be installed to the user profile using <<opt-home.packages>>.
<2> The option names of a program module typically start with `programs.<package name>`.
<3> Similarly, for a service module, the names start with `services.<package name>`. Note in some cases a package has both programs _and_ service options – Emacs is such an example.
To activate this configuration you can run
[source,console]
home-manager switch
or if you are not feeling so lucky,
[source,console]
home-manager build
which will create a `result` link to a directory containing an
activation script and the generated home directory files.
[[sec-usage-rollbacks]]
=== Rollbacks
While the `home-manager` tool does not explicitly support rollbacks at the moment it is relatively easy to perform one manually. The steps to do so are
1. Run `home-manager generations` to determine which generation you wish to rollback to:
+
[source,console]
----
$ home-manager generations
2018-01-04 11:56 : id 765 -> /nix/store/kahm1rxk77mnvd2l8pfvd4jkkffk5ijk-home-manager-generation
2018-01-03 10:29 : id 764 -> /nix/store/2wsmsliqr5yynqkdyjzb1y57pr5q2lsj-home-manager-generation
2018-01-01 12:21 : id 763 -> /nix/store/mv960kl9chn2lal5q8lnqdp1ygxngcd1-home-manager-generation
2017-12-29 21:03 : id 762 -> /nix/store/6c0k1r03fxckql4vgqcn9ccb616ynb94-home-manager-generation
2017-12-25 18:51 : id 761 -> /nix/store/czc5y6vi1rvnkfv83cs3rn84jarcgsgh-home-manager-generation
…
----
2. Copy the Nix store path of the generation you chose, e.g.,
To configure programs and services Home Manager must write various things to your home directory. To prevent overwriting any existing files when switching to a new generation, Home Manager will attempt to detect collisions between existing files and generated files. If any such collision is detected the activation will terminate before changing anything on your computer.
For example, suppose you have a wonderful, painstakingly created `~/.config/git/config` and add
[source,nix]
----
{
# …
programs.git = {
enable = true;
userName = "Jane Doe";
userEmail = "jane.doe@example.org";
};
# …
}
----
to your configuration. Attempting to switch to the generation will then result in
[source,console]
----
$ home-manager switch
…
Activating checkLinkTargets
Existing file '/home/jdoe/.config/git/config' is in the way
Please move the above files and try again
----
[[sec-usage-graphical]]
=== Graphical services
Home Manager includes a number of services intended to run in a graphical session, for example `xscreensaver` and `dunst`. Unfortunately, such services will not be started automatically unless you let Home Manager start your X session. That is, you have something like
[source,nix]
----
{
# …
services.xserver.enable = true;
# …
}
----
in your system configuration and
[source,nix]
----
{
# …
xsession.enable = true;
xsession.windowManager.command = "…";
# …
}
----
in your Home Manager configuration.
[[sec-updating]]
=== Updating
If you have installed Home Manager using the Nix channel method
then updating Home Manager is done by first updating the channel.
You can then switch to the updated Home Manager environment.
The module system in Home Manager is based entirely on the NixOS module system so we will here only highlight aspects that are specific for Home Manager. For information about the module system as such please refer to the {writing-nixos-modules}[Writing NixOS Modules] chapter of the NixOS manual.
Overall the basic option types are the same in Home Manager as NixOS. A few Home Manager options, however, make use of custom types that are worth describing in more detail. These are the option types `dagOf` and `gvariant` that are used, for example, by <<opt-programs.ssh.matchBlocks>> and <<opt-dconf.settings>>.
`hm.types.dagOf`::
Options of this type have attribute sets as values where each member is a node in a {wikipedia-dag}[directed acyclic graph] (DAG). This allows the attribute set entries to express dependency relations among themselves. This can, for example, be used to control the order of match blocks in a OpenSSH client configuration or the order of activation script blocks in <<opt-home.activation>>.
+
A number of functions are provided to create DAG nodes. The functions are shown below with examples using an option `foo.bar` of type `hm.types.dagOf types.int`.
+
`hm.dag.entryAnywhere (value: T)`:::
Indicates that `value` can be placed anywhere within the DAG. This is also the default for plain attribute set entries, that is
+
[source,nix]
----
foo.bar = {
a = hm.dag.entryAnywhere 0;
}
----
+
and
+
[source,nix]
----
foo.bar = {
a = 0;
}
----
+
are equivalent.
+
`hm.dag.entryAfter (afters: list string) (value: T)`:::
Indicates that `value` must be placed _after_ each of the attribute names in the given list. For example
+
[source,nix]
----
foo.bar = {
a = 0;
b = hm.dag.entryAfter [ "a" ] 1;
}
----
+
would place `b` after `a` in the graph.
+
`hm.dag.entryBefore (befores: list string) (value: T)`:::
Indicates that `value` must be placed _before_ each of the attribute names in the given list. For example
+
[source,nix]
----
foo.bar = {
b = hm.dag.entryBefore [ "a" ] 1;
a = 0;
}
----
+
would place `b` before `a` in the graph.
+
`hm.dag.entryBetween (befores: list string) (afters: list string) (value: T)`:::
Indicates that `value` must be placed _before_ the attribute names in the first list and _after_ the attribute names in the second list. For example
+
[source,nix]
----
foo.bar = {
a = 0;
c = hm.dag.entryBetween [ "b" ] [ "a" ] 2;
b = 1;
}
----
+
would place `c` before `b` and after `a` in the graph.
This type is useful for options representing {gvariant-description}[GVariant] values. The type accepts all primitive GVariant types as well as arrays, tuples, ``maybe'' types, and dictionaries.
+
Some Nix values are automatically coerced to matching GVariant value but the GVariant model is richer so you may need to use one of the provided constructor functions. Examples assume an option `foo.bar` of type `hm.types.gvariant`.
Takes a Nix value `v` to a GVariant `boolean` value (GVariant format string `b`). Note, Nix booleans are automatically coerced using this function. That is,
Takes a Nix value `v` to a GVariant `string` value (GVariant format string `s`). Note, Nix strings are automatically coerced using this function. That is,
Takes a Nix value `v` to a GVariant `int32` value (GVariant format string `i`). Note, Nix integers are automatically coerced using this function. That is,
Takes a Nix value `v` to a GVariant `double` value (GVariant format string `d`). Note, Nix floats are automatically coerced using this function. That is,
+
[source,nix]
----
foo.bar = hm.gvariant.mkDouble 3.14;
----
+
is equivalent to
+
[source,nix]
----
foo.bar = 3.14;
----
+
[[sec-option-types-gvariant-mkArray]]`hm.gvariant.mkArray type elements`:::
Builds a GVariant array containing the given list of elements, where each element is a GVariant value of the given type (GVariant format string `a${type}`). The `type` value can be constructed using
+
--
- `hm.gvariant.type.string` (GVariant format string `s`)
- `hm.gvariant.type.boolean` (GVariant format string `b`)
- `hm.gvariant.type.uchar` (GVariant format string `y`)
- `hm.gvariant.type.int16` (GVariant format string `n`)
- `hm.gvariant.type.uint16` (GVariant format string `q`)
- `hm.gvariant.type.int32` (GVariant format string `i`)
- `hm.gvariant.type.uint32` (GVariant format string `u`)
- `hm.gvariant.type.int64` (GVariant format string `x`)
- `hm.gvariant.type.uint64` (GVariant format string `t`)
- `hm.gvariant.type.double` (GVariant format string `d`)
- `hm.gvariant.type.variant` (GVariant format string `v`)
- `hm.gvariant.type.arrayOf type` (GVariant format string `a${type}`)
- `hm.gvariant.type.maybeOf type` (GVariant format string `m${type}`)
- `hm.gvariant.type.tupleOf types` (GVariant format string `(${lib.concatStrings types})`)
- `hm.gvariant.type.dictionaryEntryOf [keyType valueType]` (GVariant format string `{${keyType}${valueType}}`)
--
+
where `type` and `types` are themselves a type and list of types, respectively.
Builds a GVariant maybe value (GVariant format string `m${type}`) whose (non-existent) element is of the given type. The `type` value is constructed as described for the <<sec-option-types-gvariant-mkArray,`mkArray`>> function above.
Builds a GVariant dictionary entry containing the given list of elements (GVariant format string `{${key.type}${value.type}}`), where each element is a GVariant value.
$VERBOSE_RUN _i "Sanity checking oldGenNum and oldGenPath"
if[[ -v oldGenNum && ! -v oldGenPath
|| ! -v oldGenNum && -v oldGenPath ]];then
_i $'The previous generation number and path are in conflict! These\nmust be either both empty or both set but are now set to\n\n \'%s\' and \'%s\'\n\nIf you don\'t mind losing previous profile generations then\nthe easiest solution is probably to run\n\n rm %s/home-manager*\n rm %s/current-home\n\nand trying home-manager switch again. Good luck!'\
"${oldGenNum:-}""${oldGenPath:-}"\
"$profilesDir""$hmGcrootsDir"
exit1
fi
}
function checkUsername(){
localexpectedUser="$1"
if[["$USER" !="$expectedUser"]];then
_iError 'Error: USER is set to "%s" but we expect "%s"'"$USER""$expectedUser"
exit1
fi
}
function checkHomeDirectory(){
localexpectedHome="$1"
if ! [[$HOME -ef $expectedHome]];then
_iError 'Error: HOME is set to "%s" but we expect "%s"'"$HOME""$expectedHome"
exit1
fi
}
if[[ -v VERBOSE ]];then
exportVERBOSE_ECHO=echo
exportVERBOSE_ARG="--verbose"
exportVERBOSE_RUN=""
else
exportVERBOSE_ECHO=true
exportVERBOSE_ARG=""
exportVERBOSE_RUN=true
fi
_i "Starting Home Manager activation"
# Verify that we can connect to the Nix store and/or daemon. This will
# also create the necessary directories in profiles and gcroots.
$VERBOSE_RUN _i "Sanity checking Nix"
nix-build --expr '{}' --no-out-link
# Also make sure that the Nix profiles path is created.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
