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.
