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.
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.
Update translation files
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.
Co-authored-by: Hosted Weblate <hosted@weblate.org>
Translate-URL: https://hosted.weblate.org/projects/home-manager/cli/
Translate-URL: https://hosted.weblate.org/projects/home-manager/modules/
Translation: Home Manager/Home Manager CLI
Translation: Home Manager/Home Manager Modules
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
