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
On macOS, configuration files are stored in the platform-standard
directory `~/Library/Application Support/` by default. However, if the
user enables the XDG Base Directory specification by setting
`xdg.enable = true`, iamb should respect the `XDG_CONFIG_HOME`
environment variable (along with other related XDG variables).
Currently, this behavior is not implemented in iamb, a PR has been
opened to fix that -> https://github.com/ulyssa/iamb/pull/478.
This commit deprecates profile management from the activation script.
The profile management is instead the responsibility of the driving
software, for example, the `home-manager` tool in the case of
standalone installs.
The legacy behavior is still available for backwards compatibility but
may be removed in the future.
The new behavior resolves (or moves us closer to resolving) a number
of long standing open issues:
- `home-manager switch --rollback`, which performs a rollback to the
previous Home Manager generation before activating. While it was
previously possible to accomplish this by activating an old
generation, it did always create a new profile generation.
This option has been implemented as part of this commit.
- `home-manager switch --specialisation NAME`, which switches to the
named specialisation. While it was previously possible to accomplish
this by manually running the specialisation activate script, it did
always create a new profile generation.
This option has been implemented as part of this commit.
- `home-manager switch --test`, which activates the configuration but
does not create a new profile generation.
This option has _not_ been implemented here since it relies on the
current configuration being activated on login, which we do not
currently do.
- When using the "Home Manager as a NixOS module" installation method
we previously created an odd `home-manager` per-user "shadow
profile" for the user. This is no longer necessary.
This has been implemented as part of this commit.
Fixes#3450
If neither neomutt.sendMailCommand nor passCmd are set, leave
configuration for sending emails unset. This will leave neomutt to
manage sending emails itself, which matches the existing description of
the `accounts.email.accounts.<name>.neomutt.sendMailCommand`
configuration option.
This also removes the assertion added in bd680a8c (neomutt: allow
default email sending behaviour, 2025-07-12), since it is now valid to
have neither passCmd nor neomutt.sendMailCommand on an account.
When the silent flag was refactored to pass in configuration. We
accidentally introduced a bug that clobbered any `global` settings.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Since https://github.com/nushell/nushell/pull/16007, the recommended
flag to avoid erroring on missing fields is `--optional`. To avoid
compatibility issues, the builtin optional access syntax is used
instead, which is backwards-compatible.
This adds support for generating ordered children and nodes with
attributes and/or properties but no children. These are both needed to
generate zellij keybinding configuration.
VS Code 1.102 separates MCP configuration from `settings.json` to a profile-specific `mcp.json`. VS Code automatically performs this separation if MCP configuration is detected inside `settings.json` which conflicts with the immutability of the settings.json that home-manager supplies.
Currently we create a systemd unit that will throw an error when
settings aren't configured because we try to link to a file that wont be
created with empty config.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
The file grew in complexity while adding customization. Separate
concerns for each gtk versions customization and use lib helpers to
consolidate logic.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
This notably allows to specify a custom SMTP server or GPG keys, to be
able to respond as the alias without depending entirely on the parent
account's configuration.
Signed-off-by: tsrk. <tsrk@tsrk.me>
Adds extension permissions as suggested in
https://github.com/nix-community/home-manager/issues/7001.
Adds the 'profiles.<name>.extensions.settings.<name>.permissions' to Firefox
derivatives. If set, this option adds an assertion that fails if an extension
package requests permissions that weren't added to the permissions option. In
order to not require 'profiles.<name>.extensions.force' to be set when only
permissions, but no extension settings were defined, the relevant assertions
were changed. They now check whether any 'extensions.settings.<name>.settings'
was set instead of checking whether 'extensions.settings' was set.
---------
Co-authored-by: Robert Helgesson <robert@rycee.net>
Co-authored-by: awwpotato <awwpotato@voidq.com>
f there's an account under accounts.email.accounts with neomutt.enable set to true but neither passwordCommand nor neomutt.sendMailCommand set, then building the Neomutt rc file will fail. Ensure that failure has a useful error message, rather than a confusing type error.
While we're here, make the module code slightly less repetitious by just building the set of email accounts that have Neomutt enabled once, rather than multiple times in multiple contexts.
