Currently translated at 15.6% (5 of 32 strings)
Add translation using Weblate (Spanish)
Co-authored-by: Mario Rodas <rodasmario2@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/home-manager/cli/es/
Translation: Home Manager/Home Manager CLI
Translate using Weblate (Chinese (Simplified))
Currently translated at 100.0% (32 of 32 strings)
Add translation using Weblate (Chinese (Simplified))
Co-authored-by: WhiredPlanck <fungdaat31@outlook.com>
Translate-URL: https://hosted.weblate.org/projects/home-manager/cli/zh_Hans/
Translation: Home Manager/Home Manager CLI
Currently translated at 100.0% (32 of 32 strings)
Add translation using Weblate (Russian)
Co-authored-by: Mikhail Chekan <chekoopa@mail.ru>
Translate-URL: https://hosted.weblate.org/projects/home-manager/cli/ru/
Translation: Home Manager/Home Manager CLI
Currently translated at 100.0% (32 of 32 strings)
Co-authored-by: TheBlackBeans <adrien.mathieu.net@gmail.com>
Translate-URL: https://hosted.weblate.org/projects/home-manager/cli/fr/
Translation: Home Manager/Home Manager CLI
Two misplaced quotations were introduced in `doBuild` by https://github.com/nix-community/home-manager/pull/2501, which
caused the parameter expansion of DRY_RUN to include an extraneous tab. Since the flake uri is passed
later into the command, Nix assumes the whitespace sequence as the flake uri and returns that it is not
a valid flake reference.
This PR removes the misplaced quotations in `doBuild` and also places the flake uri as the first argument for
calls to `doBuildFlake` for consistency with `doBuildAttr`. Placing the uri first in the command line also guards
against possible security issues if arbitrary uris are expanded prior to the user given uri.
Currently, the `buildNews` and `doBuildAttrs` are always called
unconditionally even if a flake configuration is specified. This cause
it to always fail prior to the actual build performed by `doBuildAttrs`
because `setConfigFIle` can not find the home-manager configuration file.
As a result, an error message specifying no configuration file is shown.
Furthermore, if a user has remnant legacy configuration, the `doSwitch` and
`doBuild` functions will effectively build the activationPackage twice, with
the legacy configuration overriding the flake configuration.
A conditional check for FLAKE_CONFIG_URI was added to mitigate this by building
the legacy configuration when no flake configuration is present. There is one
exception which is when a flake configuration exists in the default location, where
the user can not build the legacy configuration as along as the file is present.
However, the tradeoff is acceptable as it matches current behavior when FLAKe_CONFIG_URI
is set for instantiation, and an user is unlikely to simulataneously switch
between the two mechanisms.
An abstract function for building flakes `doBuildFlake` was created to match
`doBuildAttrs` for manageing options and build flags.
The --no-write-lock-file flag was removed from the --debug case as it is already
matched previously at the --recreate-lock-file case.
This allows running home-manager with --builders option passed through
to nix-build, which will then pass build execution to remote builders on
other machines.
This may be useful with relatively complex home-manager configurations
where building on a local machine is not feasible.
Implements a --flake options for build and switch, along with the usual
flake related optons (for lock-files etc).
Configurations in the flake are automatically discovered in the
following order:
1. `outputs.homeConfigurations."$flake-uri"` (the `--flake parameter`)
2. `outputs.homeConfigurations."$USERNAME@$HOSTNAME"`
3. `outputs.homeConfigurations."$USERNAME"`
Make home-manager use default configuration from
~/.config/nixpkgs/flake.nix, if it exists and nothing else is
specified.
Co-authored-by: Nicolas Berbiche <nicolas@normie.dev>
This makes Home Manager respect the NO_COLOR environment variable to
disable coloring from output generated by Home Manager.
This initiative can be found more on https://no-color.org/
The quoted `$EDITOR` causes errors when using values containing
arguments, eg. "code --wait". This is in contrast to the majority of
tools (git, etc.) that do support this usage.
Fixes#1496
This option used to make the `home-manager` command use the `nix` tool
from Nix 2. Unfortunately the `nix` tool is a bit experimental and it
is best to await its stabilization before supporting it in Home
Manager.
It can be useful to simply instantiate a Home Manager configuration
without actually building it, for example for the purpose of
pre-building it with some custom command.
PR #1099
Presently, if you pass an argument with spaces in it to `doBuildAttr`,
it will be split it into multiple arguments to `nix build` or
`nix-build`. This situation arises, for example, on systems with
spaces in `XDG_DATA_HOME`.
Specifically, the `home-manager` script errors out in trying to
address the `read-news` state file. With this change, argument
separation should be preserved properly in `doBuildAttr`.
PR #1044
This forces the `home.file` option to be completely empty when
switching to the uninstall configuration. This is necessary to guard
against files are added by default in Home Manager, such as
`$XDG_CACHE_HOME/.keep`.
This sets the state version in recent installs to the latest released
version. It is beneficial for people to be aware of this option and it
is also good to help new users get a more recent setup.
This commit adds a "build" command to the install derivation that
tells the user that `nix-shell` should be used.
A derivation attribute `shellHookOnly = true` is also added with the
intent to indicate that the shell hook is the entire point of the
derivation.
This rewrite allows "long options" but unfortunately does not allow
merged options such as `-vn`.
Also improve the home-manager manual page, with this it should include
all sub-commands and arguments.
Finally, include the home-manager manual page in the generated HTML
documentation.
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
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.
