The user-service drop-in invoked activate without a driver version, so
the script defaulted to driver 0 and always managed the per-user
home-manager profile, ignoring enableLegacyProfileManagement. Use the
same version as the system service and assert both generated
user-service commands.
The Putter tool is a Rust implementation of the file management
component of Home Manager. It takes a JSON manifest that indicates how
files should be symlinked and when the manifest is applied, does its
best to ensure that the file system reflect the manifest.
Putter offers some additional features that Home Manager does not
expose today, such as file copying (potentially recursive) and support
for overriding files within a recursive tree (e.g., inside a symlinked
tree one could ensure that a specific file is copies with specific
permissions).
This is considered highly experimental at the moment and to use Putter
one must set a hidden option.
This option works with the NixOS version of the module as host services
have different user namespace permissions to user services. Programs
like ssh get confused when certain config files aren't owned by root.
Explain when to use extraSpecialArgs versus _module.args in the flake setup guides, and keep the generated standalone fixture aligned with the updated template output.
nix profile install was renamed to nix profile add in Nix 2.28.
The old name still works as a deprecated alias but produces a warning
on every home-manager switch:
warning: 'install' is a deprecated alias for 'add'
Signed-off-by: Bart Smykla <bartek@smykla.com>
Add support for kitty's automatic theme switching based on OS
color scheme. This creates the required auto theme config files:
- light-theme.auto.conf
- dark-theme.auto.conf
- no-preference-theme.auto.conf
Closes: nix-community/home-manager#6869
By default, dconf uses $XDG_CONFIG_HOME/dconf/user as the user database, but this can be changed by specifying user-db:<name> in a profile file and setting the DCONF_PROFILE environment variable to that profile. One may want to use different user databases for different DE/WMs to avoid collision.
Currently the module invokes dconf without touching DCONF_PROFILE, which means that 1) it is unable to configure multiple different user databases, and 2) the behavior of activation script will be affected by the DCONF_PROFILE environment variable when it is invoked, possibly leading to undesired results.
This PR adds a dconf.databases option, so that settings under dconf.databases.<name> will be written to $XDG_CONFIG_HOME/dconf/<name>. The old dconf.settings option is left as-is to avoid breaking compatibility.
- added a test to the standalone-basics unit: the option subcommand queries the `home.username` value and ensures that something sane is returned.
details:
- the option subcommand was broken by upstream changes to the `nixos-option` command.
- hm had no tests for the option subcommand, so the problem was discovered by users.
- output from nixos-option probably starts with 'Value:\n "alice"', but we're only looking for 'alice' because the output format is not guaranteed.
It was a bit too ambitious to also remove production of the gcroot, we
need it to keep track of the currently active Home Manager
configuration.
Fixes#7583
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
These were removed as part of dead code removal, but they are actually
needed in the integration tests for comparing with the configuration
generated by the installation.
