This represents the first step in migrating `home.file` to support
arbitrary absolute paths. This is to allow Home Manager to manage
files anywhere, provided the user has sufficient privileges.
For example, with this change the configuration
home.file."test/one".text = "foo";
home.file."/test/two".text = "foo";
will result in the files "$HOME/test/one" and "/test/two",
respectively. Note, a relative file name will still be relative
`$HOME`.
To allow a reasonable transition between the old and new path handling
we introduce the notion of "generation directory layout version". The
version is simply a file `version` within the generation directory
containing a number indicating the version number.
The version 0 (also implied if the version file is missing) indicates
the legacy layout where managed file paths always are relative
`$HOME`.
Version 1 indicates the new layout where managed file paths are
relative `/`.
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
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.
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
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.
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
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.
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
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
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`.
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
Unfortunately systemd derives nonsensical unit names when the unit
file is a link to a link to a file. This commit ensures that any file
whose target path matches the pattern `*/systemd/user/*` will be
reachable with only one link hop.
This also reverts f52ec0df7c, which
contained a temporary fix. This commit is an improvements in that it
is more explicit and also handles unit files given directly as a home
file source.
By sanitizing the home file name in the derivation name, the home file
name is no longer exposed to the naming restrictions for nix store
paths.
For example, it is now possible to define home files with spaces in
their names without providing a target or source attribute.
