With this change, running
home-manager edit
opens `$HOME_MANAGER_CONFIG` in `$EDITOR`.
This is mainly for convenience. Users should not have to remember the
exact location of the Home Manager configuration.
This avoids the uncontrollable nature of fetching the tarball as part
of the evaluation. Instead the user can decide when to update and also
perform rollbacks, if necessary.
This adds a new command to the home-manager shell script that allows
generations to be removed that are older than an given absolute or
relative date.
This allows users to manage the expiration of their home-manager
generations separately from their system or user profiles via
nix-collect-garbage. It is most important if the user desires to have
a convenient way to have different expiration times for Home Manager
generations than other system or user profiles.
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
It was previously possible to create the news information and lose it
in a Nix GC before being able to view it. This also causes a switch to
error out. This change makes the news information a root in the
garbage collector.
Note, this change also removes the need for `nix eval` so the
`doBuildAttr` function is simplified accordingly.
Fixes#327
Home Manager needs an absolute and resolved path to its configuration
file. The default configuration path is absolute but not necessarily
resolved. For example, some users may have `~/.config` be a symbolic
link to somewhere else. We therefore run the default configuration
path through the `realpath` tool to resolve it.
Fixes#304
This adds an experimantal, undocumented, and unsupported flag `-2` for
the `home-manager` command that enables the use of the new `nix`
command instead of `nix-build`.
This changes the installation command from
nix-shell $HM_PATH -A install --run 'home-manager switch'
to
nix-shell $HM_PATH -A install
The added shell hook will print some useful information and run
`home-manager switch`.
Before this path would point to the modules path. Using the project
root instead makes it possible to set `<home-manager>` to point to a
downloadable archive of Home Manager. This should make it
significantly easier to install and keep Home Manager up to date.
To match this change we also deprecate the Home Manager option
programs.home-manager.modulesPath
and instead ask users to use
programs.home-manager.path
This command allows the user to examine the news items generated by
the news module. See #52.
Many thanks to @nonsequitur and @uvNikita for suggestions and
improvements.
Using `--no-out-link` is convenient but it does not set up a GC root,
so an unfortunately timed GC could remove the generation before
activation completes. Many thanks to @nonsequitur for noting this
problem.
There is no need to specify an out link when switching to a new
generation since nix-build prints the store path on standard output.
Similarly, when just building a generation we specify no out link
since nix-build will use "result" by default.
Run the activation script in its original nix-store location so that
Bash error messages show the real script location instead of 'wrkdir',
which gets deleted right after the script exits.
Because 'set -e' has no effect on commands that run in an if condition,
the script was always exiting with no error when 'doBuild' failed.
As a bonus, $wrkdir is now always removed after building.
This commit changes the default path of the Home Manager configuration
file from `~/.nixpkgs/home.nix` to `~/.config/nixpkgs/home.nix`. The
old path is still supported and will be used if the `.config` path
does not exist.
This aligns Home Manager with the preferred configuration directory in
NixOS 17.03.
Fixes#13.
This removes the old argument based method that Home Manager used to
find its modules by a `NIX_PATH` based method. Specifically, this adds
a `home-manager` Nix path prefix that can be overridden much like with
the `nixpkgs` path prefix.
For example, with these settings Bash will complain if uninitialized
variables are used. Some code has been improved to run cleanly with
these settings.
Nix needs an absolute path and the user may have given a relative path
for the configuration file. We therefore need to expand it using the
`realpath` tool.