mirror of
https://github.com/nix-community/home-manager
synced 2024-11-01 00:39:45 +01:00
docs: migrate documentation
This resolves the long-standing deprecation warning by migrating the documentation to using the nixos-render-docs tool. As part of this, the documentation markup language is migrated to Markdown. See pull-request #4673 for more.
This commit is contained in:
Robert Helgesson
commit
7db6291d95
57 changed files with 2548 additions and 2454 deletions
|
|
@ -1,22 +0,0 @@
|
||||||
[[ch-3rd-party]]
|
|
||||||
== Third-Party Tools and Extensions
|
|
||||||
|
|
||||||
Here is a collection of tools and extensions that relate to Home
|
|
||||||
Manager. Note, these are maintained outside the regular Home Manager
|
|
||||||
flow so quality and support may vary wildly. If you encounter problems
|
|
||||||
then please raise them in the corresponding project, not as issues in
|
|
||||||
the Home Manager tracker.
|
|
||||||
|
|
||||||
If you have made something interesting related to Home Manager then
|
|
||||||
you are encouraged to create a PR that expands this chapter.
|
|
||||||
|
|
||||||
[[sec-3rd-party-module-collections]]
|
|
||||||
=== Module Collections
|
|
||||||
|
|
||||||
- https://github.com/schuelermine/xhmm[xhmm — extra Home Manager modules]
|
|
||||||
+
|
|
||||||
A collection of modules maintained by Anselm Schüler.
|
|
||||||
|
|
||||||
- https://github.com/danth/stylix/[Stylix — System-wide colorscheming and typography]
|
|
||||||
+
|
|
||||||
Configure your applications to get coherent color scheme and font.
|
|
||||||
|
|
@ -1,266 +0,0 @@
|
||||||
[[ch-contributing]]
|
|
||||||
== Contributing
|
|
||||||
|
|
||||||
:open-issues: https://github.com/nix-community/home-manager/issues
|
|
||||||
:new-issue: https://github.com/nix-community/home-manager/issues/new
|
|
||||||
:fork-a-repo: https://help.github.com/articles/fork-a-repo/
|
|
||||||
:create-a-pull-request: https://help.github.com/articles/creating-a-pull-request/
|
|
||||||
:seven-rules: https://chris.beams.io/posts/git-commit/#seven-rules
|
|
||||||
:news-nix: https://github.com/nix-community/home-manager/blob/master/modules/misc/news.nix
|
|
||||||
:nixfmt: https://github.com/serokell/nixfmt/
|
|
||||||
:example-commit-message: https://github.com/nix-community/home-manager/commit/69f8e47e9e74c8d3d060ca22e18246b7f7d988ef
|
|
||||||
|
|
||||||
Contributions to Home Manager are very welcome. To make the process as smooth as possible for both you and the Home Manager maintainers we provide some guidelines that we ask you to follow. See <<sec-contrib-getting-started>> for information on how to set up a suitable development environment and <<sec-guidelines>> for the actual guidelines.
|
|
||||||
|
|
||||||
This text is mainly directed at those who would like to make code contributions to Home Manager. If you just want to report a bug then first look among the already {open-issues}[open issues], if you find one matching yours then feel free to comment on it to add any additional information you may have. If no matching issue exists then go to the {new-issue}[new issue] page and write a description of your problem. Include as much information as you can, ideally also include relevant excerpts from your Home Manager configuration.
|
|
||||||
|
|
||||||
[[sec-contrib-getting-started]]
|
|
||||||
=== Getting started
|
|
||||||
|
|
||||||
If you have not previously forked Home Manager then you need to do that first. Have a look at GitHub's {fork-a-repo}[Fork a repo] for instructions on how to do this.
|
|
||||||
|
|
||||||
Once you have a fork of Home Manager you should create a branch starting at the most recent `master` branch. Give your branch a reasonably descriptive name. Commit your changes to this branch and when you are happy with the result and it fulfills <<sec-guidelines>> then push the branch to GitHub and {create-a-pull-request}[create a pull request].
|
|
||||||
|
|
||||||
Assuming your clone is at `$HOME/devel/home-manager` then you can make the `home-manager` command use it by either
|
|
||||||
|
|
||||||
1. overriding the default path by using the `-I` command line option:
|
|
||||||
+
|
|
||||||
[source,console]
|
|
||||||
$ home-manager -I home-manager=$HOME/devel/home-manager
|
|
||||||
+
|
|
||||||
or, if using <<sec-flakes-standalone,flakes>>:
|
|
||||||
+
|
|
||||||
[source,console]
|
|
||||||
$ home-manager --override-input home-manager ~/devel/home-manager
|
|
||||||
+
|
|
||||||
or
|
|
||||||
|
|
||||||
2. changing the default path by ensuring your configuration includes
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
programs.home-manager.enable = true;
|
|
||||||
programs.home-manager.path = "$HOME/devel/home-manager";
|
|
||||||
----
|
|
||||||
+
|
|
||||||
and running `home-manager switch` to activate the change. Afterwards, `home-manager build` and `home-manager switch` will use your cloned repository.
|
|
||||||
|
|
||||||
The first option is good if you only temporarily want to use your clone.
|
|
||||||
|
|
||||||
[[sec-guidelines]]
|
|
||||||
=== Guidelines
|
|
||||||
:irc-home-manager: https://webchat.oftc.net/?channels=home-manager
|
|
||||||
:valuable-options: https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md#valuable-options
|
|
||||||
:rfc-42: https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md
|
|
||||||
:assertions: https://nixos.org/manual/nixos/stable/index.html#sec-assertions
|
|
||||||
|
|
||||||
If your contribution satisfy the following rules then there is a good chance it will be merged without too much trouble. The rules are enforced by the Home Manager maintainers and to a lesser extent the Home Manager CI system.
|
|
||||||
|
|
||||||
If you are uncertain how these rules affect the change you would like to make then feel free to start a discussion in the {irc-home-manager}[#home-manager] IRC channel, ideally before you start developing.
|
|
||||||
|
|
||||||
[[sec-guidelines-back-compat]]
|
|
||||||
==== Maintain backward compatibility
|
|
||||||
|
|
||||||
Your contribution should not cause another user's existing configuration to break unless there is a very good reason and the change should be announced to the user through an {assertions}[assertion] or similar.
|
|
||||||
|
|
||||||
Remember that Home Manager is used in many different environments and you should consider how your change may effect others. For example,
|
|
||||||
|
|
||||||
- Does your change work for people that do not use NixOS? Consider other GNU/Linux distributions and macOS.
|
|
||||||
- Does your change work for people whose configuration is built on one system and deployed on another system?
|
|
||||||
|
|
||||||
[[sec-guidelines-forward-compat]]
|
|
||||||
==== Keep forward compatibility in mind
|
|
||||||
|
|
||||||
The master branch of Home Manager tracks the unstable channel of Nixpkgs, which may update package versions at any time. It is therefore important to consider how a package update may affect your code and try to reduce the risk of breakage.
|
|
||||||
|
|
||||||
The most effective way to reduce this risk is to follow the advice in <<sec-guidelines-valuable-options>>.
|
|
||||||
|
|
||||||
[[sec-guidelines-valuable-options]]
|
|
||||||
==== Add only valuable options
|
|
||||||
|
|
||||||
When creating a new module it is tempting to include every option supported by the software. This is _strongly_ discouraged. Providing many options increases maintenance burden and risk of breakage considerably. This is why only the most {valuable-options}[important software options] should be modeled explicitly. Less important options should be expressible through an `extraConfig` escape hatch.
|
|
||||||
|
|
||||||
A good rule of thumb for the first implementation of a module is to only add explicit options for those settings that absolutely must be set for the software to function correctly. It follows that a module for software that provides sensible default values for all settings would require no explicit options at all.
|
|
||||||
|
|
||||||
If the software uses a structured configuration format like a JSON, YAML, INI, TOML, or even a plain list of key/value pairs then consider using a `settings` option as described in {rfc-42}[Nix RFC 42].
|
|
||||||
|
|
||||||
[[sec-guidelines-add-tests]]
|
|
||||||
==== Add relevant tests
|
|
||||||
|
|
||||||
If at all possible, make sure to add new tests and expand existing tests so that your change will keep working in the future. See <<sec-tests>> for more information about the Home Manager test suite.
|
|
||||||
|
|
||||||
All contributed code _must_ pass the test suite.
|
|
||||||
|
|
||||||
[[sec-guidelines-module-maintainer]]
|
|
||||||
|
|
||||||
==== Add relevant documentation
|
|
||||||
:nixpkgs-markdown: https://nixos.org/manual/nixpkgs/unstable/#sec-contributing-markup
|
|
||||||
:docbook: https://tdg.docbook.org/
|
|
||||||
:asciidoc: https://asciidoc.org/
|
|
||||||
|
|
||||||
Many code changes require changing the documentation as well. Module options should be documented with {nixpkgs-markdown}[Nixpkgs-flavoured Markdown]. Home Manager is itself documented using a combination of {docbook}[DocBook] and {asciidoc}[AsciiDoc]. All text is hosted in Home Manager's Git repository.
|
|
||||||
|
|
||||||
The HTML version of the manual containing both the module option descriptions and the documentation of Home Manager can be generated and opened by typing the following in a shell within a clone of the Home Manager Git repository:
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
$ nix-build -A docs.html
|
|
||||||
$ xdg-open ./result/share/doc/home-manager/index.html
|
|
||||||
|
|
||||||
When you have made changes to a module, it is a good idea to check that the man page version of the module options looks good:
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
$ nix-build -A docs.manPages
|
|
||||||
$ man ./result/share/man/man5/home-configuration.nix.5.gz
|
|
||||||
|
|
||||||
==== Add yourself as a module maintainer
|
|
||||||
|
|
||||||
Every new module _must_ include a named maintainer using the `meta.maintainers` attribute. If you are a user of a module that currently lacks a maintainer then please consider adopting it.
|
|
||||||
|
|
||||||
If you are present in the nixpkgs maintainer list then you can use that entry. If you are not then you can add yourself to `modules/lib/maintainers.nix` in the Home Manager project.
|
|
||||||
|
|
||||||
Maintainers are encouraged to join the IRC or Matrix channel and participate when they have opportunity.
|
|
||||||
|
|
||||||
[[sec-guidelines-code-style]]
|
|
||||||
==== Format your code
|
|
||||||
|
|
||||||
Make sure your code is formatted as described in <<sec-code-style>>. To maintain consistency throughout the project you are encouraged to browse through existing code and adopt its style also in new code.
|
|
||||||
|
|
||||||
[[sec-guidelines-commit-message-style]]
|
|
||||||
==== Format your commit messages
|
|
||||||
|
|
||||||
Similar to <<sec-guidelines-code-style>> we encourage a consistent commit message format as described in <<sec-commit-style>>.
|
|
||||||
|
|
||||||
[[sec-guidelines-news-style]]
|
|
||||||
==== Format your news entries
|
|
||||||
|
|
||||||
If your contribution includes a change that should be communicated to users of Home Manager then you can add a news entry. The entry must be formatted as described in <<sec-news>>.
|
|
||||||
|
|
||||||
When new modules are added a news entry should be included but you do not need to create this entry manually. The merging maintainer will create the entry for you. This is to reduce the risk of merge conflicts.
|
|
||||||
|
|
||||||
[[sec-guidelines-conditional-modules]]
|
|
||||||
==== Use conditional modules and news
|
|
||||||
|
|
||||||
Home Manager includes a number of modules that are only usable on some of the supported platforms. The most common example of platform specific modules are those that define systemd user services, which only works on Linux systems.
|
|
||||||
|
|
||||||
If you add a module that is platform specific then make sure to include a condition in the `loadModule` function call. This will make the module accessible only on systems where the condition evaluates to `true`.
|
|
||||||
|
|
||||||
Similarly, if you are adding a news entry then it should be shown only to users that may find it relevant, see <<sec-news>> for a description of conditional news.
|
|
||||||
|
|
||||||
[[sec-guidelines-licensing]]
|
|
||||||
==== Mind the license
|
|
||||||
|
|
||||||
The Home Manager project is covered by the MIT license and we can only accept contributions that fall under this license, or are licensed in a compatible way. When you contribute self written code and documentation it is assumed that you are doing so under the MIT license.
|
|
||||||
|
|
||||||
A potential gotcha with respect to licensing are option descriptions. Often it is convenient to copy from the upstream software documentation. When this is done it is important to verify that the license of the upstream documentation allows redistribution under the terms of the MIT license.
|
|
||||||
|
|
||||||
[[sec-commit-style]]
|
|
||||||
=== Commits
|
|
||||||
|
|
||||||
The commits in your pull request should be reasonably self-contained, that is, each commit should make sense in isolation. In particular, you will be asked to amend any commit that introduces syntax errors or similar problems even if they are fixed in a later commit.
|
|
||||||
|
|
||||||
The commit messages should follow the {seven-rules}[seven rules], except for "Capitalize the subject line". We also ask you to include the affected code component or module in the first line. That is, a commit message should follow the template
|
|
||||||
|
|
||||||
----
|
|
||||||
{component}: {description}
|
|
||||||
|
|
||||||
{long description}
|
|
||||||
----
|
|
||||||
|
|
||||||
where `{component}` refers to the code component (or module) your change affects, `{description}` is a very brief description of your change, and `{long description}` is an optional clarifying description. As a rare exception, if there is no clear component, or your change affects many components, then the `{component}` part is optional. See <<ex-commit-message>> for a commit message that fulfills these requirements.
|
|
||||||
|
|
||||||
[[ex-commit-message]]
|
|
||||||
.Compliant commit message
|
|
||||||
===============================================================================
|
|
||||||
The commit {example-commit-message}[69f8e47e9e74c8d3d060ca22e18246b7f7d988ef] contains the commit message
|
|
||||||
|
|
||||||
----
|
|
||||||
starship: allow running in Emacs if vterm is used
|
|
||||||
|
|
||||||
The vterm buffer is backed by libvterm and can handle Starship prompts
|
|
||||||
without issues.
|
|
||||||
----
|
|
||||||
|
|
||||||
which ticks all the boxes necessary to be accepted in Home Manager.
|
|
||||||
===============================================================================
|
|
||||||
|
|
||||||
Finally, when adding a new module, say `programs/foo.nix`, we use the fixed commit format `foo: add module`. You can, of course, still include a long description if you wish.
|
|
||||||
|
|
||||||
[[sec-code-style]]
|
|
||||||
=== Code Style
|
|
||||||
|
|
||||||
The code in Home Manager is formatted by the {nixfmt}[nixfmt] tool and the formatting is checked in the pull request tests. Run the `format` tool inside the project repository before submitting your pull request.
|
|
||||||
|
|
||||||
Keep lines at a reasonable width, ideally 80 characters or less. This also applies to string literals.
|
|
||||||
|
|
||||||
We prefer `lowerCamelCase` for variable and attribute names with the accepted exception of variables directly referencing packages in Nixpkgs which use a hyphenated style. For example, the Home Manager option `services.gpg-agent.enableSshSupport` references the `gpg-agent` package in Nixpkgs.
|
|
||||||
|
|
||||||
[[sec-news]]
|
|
||||||
=== News
|
|
||||||
|
|
||||||
Home Manager includes a system for presenting news to the user. When making a change you, therefore, have the option to also include an associated news entry. In general, a news entry should only be added for truly noteworthy news. For example, a bug fix or new option does generally not need a news entry.
|
|
||||||
|
|
||||||
If you do have a change worthy of a news entry then please add one in {news-nix}[`news.nix`] but you should follow some basic guidelines:
|
|
||||||
|
|
||||||
- The entry timestamp should be in ISO-8601 format having "+00:00" as time zone. For example, "2017-09-13T17:10:14+00:00". A suitable timestamp can be produced by the command
|
|
||||||
+
|
|
||||||
[source,console]
|
|
||||||
$ date --iso-8601=second --universal
|
|
||||||
|
|
||||||
- The entry condition should be as specific as possible. For example, if you are changing or deprecating a specific option then you could restrict the news to those users who actually use this option.
|
|
||||||
|
|
||||||
- Wrap the news message so that it will fit in the typical terminal, that is, at most 80 characters wide. Ideally a bit less.
|
|
||||||
|
|
||||||
- Unlike commit messages, news will be read without any connection to the Home Manager source code. It is therefore important to make the message understandable in isolation and to those who do not have knowledge of the Home Manager internals. To this end it should be written in more descriptive, prose like way.
|
|
||||||
|
|
||||||
- If you refer to an option then write its full attribute path. That is, instead of writing
|
|
||||||
+
|
|
||||||
----
|
|
||||||
The option 'foo' has been deprecated, please use 'bar' instead.
|
|
||||||
----
|
|
||||||
+
|
|
||||||
it should read
|
|
||||||
+
|
|
||||||
----
|
|
||||||
The option 'services.myservice.foo' has been deprecated, please
|
|
||||||
use 'services.myservice.bar' instead.
|
|
||||||
----
|
|
||||||
|
|
||||||
- A new module, say `foo.nix`, should always include a news entry that has a message along the lines of
|
|
||||||
+
|
|
||||||
----
|
|
||||||
A new module is available: 'services.foo'.
|
|
||||||
----
|
|
||||||
+
|
|
||||||
If the module is platform specific, e.g., a service module using systemd, then a condition like
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
condition = hostPlatform.isLinux;
|
|
||||||
+
|
|
||||||
should be added. If you contribute a module then you don't need to add this entry, the merger will create an entry for you.
|
|
||||||
|
|
||||||
[[sec-tests]]
|
|
||||||
=== Tests
|
|
||||||
|
|
||||||
Home Manager includes a basic test suite and it is highly recommended to include at least one test when adding a module. Tests are typically in the form of "golden tests" where, for example, a generated configuration file is compared to a known correct file.
|
|
||||||
|
|
||||||
It is relatively easy to create tests by modeling the existing tests, found in the `tests` project directory. For a full reference to the functions available in test scripts, you can look at NMT's https://git.sr.ht/~rycee/nmt/tree/master/item/bash-lib[bash-lib].
|
|
||||||
|
|
||||||
The full Home Manager test suite can be run by executing
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
$ nix-shell --pure tests -A run.all
|
|
||||||
|
|
||||||
in the project root. List all test cases through
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
$ nix-shell --pure tests -A list
|
|
||||||
|
|
||||||
and run an individual test, for example `alacritty-empty-settings`, through
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
$ nix-shell --pure tests -A run.alacritty-empty-settings
|
|
||||||
|
|
||||||
However, those invocations will impurely source the system’s nixpkgs, and may cause failures. To run against the nixpkgs from the flake.lock, use instead e.g.
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
$ nix develop --ignore-environment .#all
|
|
||||||
|
|
@ -9,8 +9,8 @@ let
|
||||||
|
|
||||||
nmdSrc = fetchTarball {
|
nmdSrc = fetchTarball {
|
||||||
url =
|
url =
|
||||||
"https://git.sr.ht/~rycee/nmd/archive/824a380546b5d0d0eb701ff8cd5dbafb360750ff.tar.gz";
|
"https://git.sr.ht/~rycee/nmd/archive/f18defadcc25e69e95b04493ee02682005472255.tar.gz";
|
||||||
sha256 = "0vvj40k6bw8ssra8wil9rqbsznmfy1kwy7cihvm13rajwdg9ycgg";
|
sha256 = "14fazjqbc6sfsxycwadfhcymi37xg5wmrlvg3jb8d4mpbcdwfwz4";
|
||||||
};
|
};
|
||||||
|
|
||||||
nmd = import nmdSrc {
|
nmd = import nmdSrc {
|
||||||
|
|
@ -92,32 +92,38 @@ let
|
||||||
optionIdPrefix = "nix-darwin-opt-";
|
optionIdPrefix = "nix-darwin-opt-";
|
||||||
};
|
};
|
||||||
|
|
||||||
docs = nmd.buildDocBookDocs {
|
release-config = builtins.fromJSON (builtins.readFile ../release.json);
|
||||||
pathName = "home-manager";
|
revision = "release-${release-config.release}";
|
||||||
projectName = "Home Manager";
|
# Generate the `man home-configuration.nix` package
|
||||||
modulesDocs = [{
|
home-configuration-manual =
|
||||||
docBook = pkgs.linkFarm "hm-module-docs-for-nmd" {
|
pkgs.runCommand "home-configuration-reference-manpage" {
|
||||||
"nmd-result/home-manager-options.xml" = hmOptionsDocs.optionsDocBook;
|
nativeBuildInputs =
|
||||||
"nmd-result/nix-darwin-options.xml" =
|
[ pkgs.buildPackages.installShellFiles pkgs.nixos-render-docs ];
|
||||||
nixDarwinOptionsDocs.optionsDocBook;
|
allowedReferences = [ "out" ];
|
||||||
"nmd-result/nixos-options.xml" = nixosOptionsDocs.optionsDocBook;
|
} ''
|
||||||
};
|
# Generate manpages.
|
||||||
}];
|
mkdir -p $out/share/man/man5
|
||||||
documentsDirectory = ./.;
|
mkdir -p $out/share/man/man1
|
||||||
documentType = "book";
|
nixos-render-docs -j $NIX_BUILD_CORES options manpage \
|
||||||
chunkToc = ''
|
--revision ${revision} \
|
||||||
<toc>
|
--header ${./home-configuration-nix-header.5} \
|
||||||
<d:tocentry xmlns:d="http://docbook.org/ns/docbook" linkend="book-home-manager-manual"><?dbhtml filename="index.html"?>
|
--footer ${./home-configuration-nix-footer.5} \
|
||||||
<d:tocentry linkend="ch-options"><?dbhtml filename="options.html"?></d:tocentry>
|
${hmOptionsDocs.optionsJSON}/share/doc/nixos/options.json \
|
||||||
<d:tocentry linkend="ch-nixos-options"><?dbhtml filename="nixos-options.html"?></d:tocentry>
|
$out/share/man/man5/home-configuration.nix.5
|
||||||
<d:tocentry linkend="ch-nix-darwin-options"><?dbhtml filename="nix-darwin-options.html"?></d:tocentry>
|
cp ${./home-manager.1} $out/share/man/man1/home-manager.1
|
||||||
<d:tocentry linkend="ch-tools"><?dbhtml filename="tools.html"?></d:tocentry>
|
|
||||||
<d:tocentry linkend="ch-release-notes"><?dbhtml filename="release-notes.html"?></d:tocentry>
|
|
||||||
</d:tocentry>
|
|
||||||
</toc>
|
|
||||||
'';
|
'';
|
||||||
|
# Generate the HTML manual pages
|
||||||
|
home-manager-manual = pkgs.callPackage ./home-manager-manual.nix {
|
||||||
|
nmd = nmdSrc;
|
||||||
|
home-manager-options = {
|
||||||
|
home-manager = hmOptionsDocs.optionsJSON;
|
||||||
|
nixos = nixosOptionsDocs.optionsJSON;
|
||||||
|
nix-darwin = nixDarwinOptionsDocs.optionsJSON;
|
||||||
};
|
};
|
||||||
|
inherit revision;
|
||||||
|
};
|
||||||
|
html = home-manager-manual;
|
||||||
|
htmlOpenTool = pkgs.callPackage ./html-open-tool.nix { } { inherit html; };
|
||||||
in {
|
in {
|
||||||
inherit nmdSrc;
|
inherit nmdSrc;
|
||||||
|
|
||||||
|
|
@ -138,9 +144,9 @@ in {
|
||||||
'';
|
'';
|
||||||
};
|
};
|
||||||
|
|
||||||
manPages = docs.manPages;
|
manPages = home-configuration-manual;
|
||||||
|
|
||||||
manual = { inherit (docs) html htmlOpenTool; };
|
manual = { inherit html htmlOpenTool; };
|
||||||
|
|
||||||
# Unstable, mainly for CI.
|
# Unstable, mainly for CI.
|
||||||
jsonModuleMaintainers = pkgs.writeText "hm-module-maintainers.json" (let
|
jsonModuleMaintainers = pkgs.writeText "hm-module-maintainers.json" (let
|
||||||
|
|
|
||||||
192
docs/faq.adoc
192
docs/faq.adoc
|
|
@ -1,192 +0,0 @@
|
||||||
[[ch-faq]]
|
|
||||||
== Frequently Asked Questions (FAQ)
|
|
||||||
|
|
||||||
=== Why is there a collision error when switching generation?
|
|
||||||
|
|
||||||
Home Manager currently installs packages into the user environment, precisely as if the packages were installed through `nix-env --install`. This means that you will get a collision error if your Home Manager configuration attempts to install a package that you already have installed manually, that is, packages that shows up when you run `nix-env --query`.
|
|
||||||
|
|
||||||
For example, imagine you have the `hello` package installed in your environment
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ nix-env --query
|
|
||||||
hello-2.10
|
|
||||||
----
|
|
||||||
|
|
||||||
and your Home Manager configuration contains
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
home.packages = [ pkgs.hello ];
|
|
||||||
----
|
|
||||||
|
|
||||||
Then attempting to switch to this configuration will result in an error similar to
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ home-manager switch
|
|
||||||
these derivations will be built:
|
|
||||||
/nix/store/xg69wsnd1rp8xgs9qfsjal017nf0ldhm-home-manager-path.drv
|
|
||||||
[…]
|
|
||||||
Activating installPackages
|
|
||||||
replacing old ‘home-manager-path’
|
|
||||||
installing ‘home-manager-path’
|
|
||||||
building path(s) ‘/nix/store/b5c0asjz9f06l52l9812w6k39ifr49jj-user-environment’
|
|
||||||
Wide character in die at /nix/store/64jc9gd2rkbgdb4yjx3nrgc91bpjj5ky-buildenv.pl line 79.
|
|
||||||
collision between ‘/nix/store/fmwa4axzghz11cnln5absh31nbhs9lq1-home-manager-path/bin/hello’ and ‘/nix/store/c2wyl8b9p4afivpcz8jplc9kis8rj36d-hello-2.10/bin/hello’; use ‘nix-env --set-flag priority NUMBER PKGNAME’ to change the priority of one of the conflicting packages
|
|
||||||
builder for ‘/nix/store/b37x3s7pzxbasfqhaca5dqbf3pjjw0ip-user-environment.drv’ failed with exit code 2
|
|
||||||
error: build of ‘/nix/store/b37x3s7pzxbasfqhaca5dqbf3pjjw0ip-user-environment.drv’ failed
|
|
||||||
----
|
|
||||||
|
|
||||||
The solution is typically to uninstall the package from the environment using `nix-env --uninstall` and reattempt the Home Manager generation switch.
|
|
||||||
|
|
||||||
You could also opt to unistall _all_ of the packages from your profile with `nix-env --uninstall '*'`.
|
|
||||||
|
|
||||||
=== Why are the session variables not set?
|
|
||||||
:foreign-env: https://github.com/oh-my-fish/plugin-foreign-env
|
|
||||||
|
|
||||||
Home Manager is only able to set session variables automatically if it manages your Bash, Z shell, or fish shell configuration. To enable such management you use <<opt-programs.bash.enable>>, <<opt-programs.zsh.enable>>, or <<opt-programs.fish.enable>>.
|
|
||||||
|
|
||||||
If you don't want to let Home Manager manage your shell then you will have to manually source the `~/.nix-profile/etc/profile.d/hm-session-vars.sh` file in an appropriate way. In Bash and Z shell this can be done by adding
|
|
||||||
|
|
||||||
[source,bash]
|
|
||||||
----
|
|
||||||
. "$HOME/.nix-profile/etc/profile.d/hm-session-vars.sh"
|
|
||||||
----
|
|
||||||
|
|
||||||
to your `.profile` and `.zshrc` files, respectively. The `hm-session-vars.sh` file should work in most Bourne-like shells. For fish shell, it is possible to source it using {foreign-env}[the foreign-env plugin]
|
|
||||||
|
|
||||||
[source,bash]
|
|
||||||
----
|
|
||||||
fenv source "$HOME/.nix-profile/etc/profile.d/hm-session-vars.sh" > /dev/null
|
|
||||||
----
|
|
||||||
|
|
||||||
=== How to set up a configuration for multiple users/machines?
|
|
||||||
:post-your-homenix: https://www.reddit.com/r/NixOS/comments/9bb9h9/post_your_homemanager_homenix_file/
|
|
||||||
|
|
||||||
A typical way to prepare a repository of configurations for multiple logins and machines is to prepare one "top-level" file for each unique combination.
|
|
||||||
|
|
||||||
For example, if you have two machines, called "kronos" and "rhea" on which you want to configure your user "jane" then you could create the files
|
|
||||||
|
|
||||||
- `kronos-jane.nix`,
|
|
||||||
- `rhea-jane.nix`, and
|
|
||||||
- `common.nix`
|
|
||||||
|
|
||||||
in your repository.
|
|
||||||
On the kronos and rhea machines you can then make
|
|
||||||
`~jane/.config/home-manager/home.nix`
|
|
||||||
be a symbolic link to the corresponding file in your configuration repository.
|
|
||||||
|
|
||||||
The `kronos-jane.nix` and `rhea-jane.nix` files follow the format
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
{ ... }:
|
|
||||||
|
|
||||||
{
|
|
||||||
imports = [ ./common.nix ];
|
|
||||||
|
|
||||||
# Various options that are specific for this machine/user.
|
|
||||||
}
|
|
||||||
----
|
|
||||||
|
|
||||||
while the `common.nix` file contains configuration shared across the two logins. Of course, instead of just a single `common.nix` file you can have multiple ones, even one per program or service.
|
|
||||||
|
|
||||||
You can get some inspiration from the {post-your-homenix}[Post your home-manager home.nix file!] Reddit thread.
|
|
||||||
|
|
||||||
=== Why do I get an error message about `ca.desrt.dconf` or `dconf.service`?
|
|
||||||
|
|
||||||
You are most likely trying to configure something that uses dconf
|
|
||||||
but the DBus session is not aware of the dconf service.
|
|
||||||
The full error you might get is
|
|
||||||
|
|
||||||
----
|
|
||||||
error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name ca.desrt.dconf was not provided by any .service files
|
|
||||||
----
|
|
||||||
|
|
||||||
or
|
|
||||||
|
|
||||||
----
|
|
||||||
error: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit dconf.service not found.
|
|
||||||
----
|
|
||||||
|
|
||||||
The solution on NixOS is to add
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
programs.dconf.enable = true;
|
|
||||||
|
|
||||||
to your system configuration.
|
|
||||||
|
|
||||||
=== How do I install packages from Nixpkgs unstable?
|
|
||||||
|
|
||||||
If you are using a stable version of Nixpkgs but would like to install some particular packages from Nixpkgs unstable – or some other channel – then you can import the unstable Nixpkgs and refer to its packages within your configuration. Something like
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
{ pkgs, config, ... }:
|
|
||||||
|
|
||||||
let
|
|
||||||
|
|
||||||
pkgsUnstable = import <nixpkgs-unstable> {};
|
|
||||||
|
|
||||||
in
|
|
||||||
|
|
||||||
{
|
|
||||||
home.packages = [
|
|
||||||
pkgsUnstable.foo
|
|
||||||
];
|
|
||||||
|
|
||||||
# …
|
|
||||||
}
|
|
||||||
----
|
|
||||||
|
|
||||||
should work provided you have a Nix channel called `nixpkgs-unstable`.
|
|
||||||
|
|
||||||
You can add the `nixpkgs-unstable` channel by running
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ nix-channel --add https://nixos.org/channels/nixpkgs-unstable nixpkgs-unstable
|
|
||||||
$ nix-channel --update
|
|
||||||
----
|
|
||||||
|
|
||||||
Note, the package will not be affected by any package overrides, overlays, etc.
|
|
||||||
|
|
||||||
=== How do I override the package used by a module?
|
|
||||||
:nixpkgs-overlays: https://nixos.org/nixpkgs/manual/#chap-overlays
|
|
||||||
|
|
||||||
By default Home Manager will install the package provided by your chosen `nixpkgs` channel but occasionally you might end up needing to change this package. This can typically be done in two ways.
|
|
||||||
|
|
||||||
1. If the module provides a `package` option, such as `programs.beets.package`, then this is the recommended way to perform the override. For example,
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
programs.beets.package = pkgs.beets.override { enableCheck = true; };
|
|
||||||
|
|
||||||
2. If no `package` option is available then you can typically override the relevant package using an {nixpkgs-overlays}[overlay].
|
|
||||||
+
|
|
||||||
For example, if you want to use the `programs.skim` module but use the `skim` package from Nixpkgs unstable, then a configuration like
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
{ pkgs, config, ... }:
|
|
||||||
|
|
||||||
let
|
|
||||||
|
|
||||||
pkgsUnstable = import <nixpkgs-unstable> {};
|
|
||||||
|
|
||||||
in
|
|
||||||
|
|
||||||
{
|
|
||||||
programs.skim.enable = true;
|
|
||||||
|
|
||||||
nixpkgs.overlays = [
|
|
||||||
(self: super: {
|
|
||||||
skim = pkgsUnstable.skim;
|
|
||||||
})
|
|
||||||
];
|
|
||||||
|
|
||||||
# …
|
|
||||||
}
|
|
||||||
----
|
|
||||||
+
|
|
||||||
should work OK.
|
|
||||||
8
docs/highlight-style.css
Normal file
8
docs/highlight-style.css
Normal file
|
|
@ -0,0 +1,8 @@
|
||||||
|
pre {
|
||||||
|
padding: 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
pre code.hljs {
|
||||||
|
border: none;
|
||||||
|
margin: 0;
|
||||||
|
}
|
||||||
3
docs/home-configuration-nix-footer.5
Normal file
3
docs/home-configuration-nix-footer.5
Normal file
|
|
@ -0,0 +1,3 @@
|
||||||
|
.SH "AUTHORS"
|
||||||
|
.PP
|
||||||
|
Home Manager contributors
|
||||||
17
docs/home-configuration-nix-header.5
Normal file
17
docs/home-configuration-nix-header.5
Normal file
|
|
@ -0,0 +1,17 @@
|
||||||
|
.TH "HOME-CONFIGURATION\&.NIX" "5" "01/01/1980" "Home Manager"
|
||||||
|
.\" disable hyphenation
|
||||||
|
.nh
|
||||||
|
.\" disable justification (adjust text to left margin only)
|
||||||
|
.ad l
|
||||||
|
.\" enable line breaks after slashes
|
||||||
|
.cflags 4 /
|
||||||
|
.SH "NAME"
|
||||||
|
\fIhome\-configuration\&.nix\fP \- Home Manager configuration specification
|
||||||
|
.SH "DESCRIPTION"
|
||||||
|
.sp
|
||||||
|
The file ~/\&.config/home\-manager/home\&.nix contains the declarative specification of your Home Manager configuration\&. The command \fBhome\-manager\fR takes this file and realises the user environment configuration specified therein\&.
|
||||||
|
.SH "OPTIONS"
|
||||||
|
.PP
|
||||||
|
You can use the following options in
|
||||||
|
home\-configuration\&.nix:
|
||||||
|
.PP
|
||||||
60
docs/home-manager-manual.nix
Normal file
60
docs/home-manager-manual.nix
Normal file
|
|
@ -0,0 +1,60 @@
|
||||||
|
{ stdenv, lib, documentation-highlighter, nmd, revision, home-manager-options
|
||||||
|
, nixos-render-docs }:
|
||||||
|
let outputPath = "share/doc/home-manager";
|
||||||
|
in stdenv.mkDerivation {
|
||||||
|
name = "home-manager-manual";
|
||||||
|
|
||||||
|
nativeBuildInputs = [ nixos-render-docs ];
|
||||||
|
|
||||||
|
src = ./manual;
|
||||||
|
|
||||||
|
buildPhase = ''
|
||||||
|
mkdir -p out/media
|
||||||
|
|
||||||
|
mkdir -p out/highlightjs
|
||||||
|
cp -t out/highlightjs \
|
||||||
|
${documentation-highlighter}/highlight.pack.js \
|
||||||
|
${documentation-highlighter}/LICENSE \
|
||||||
|
${documentation-highlighter}/mono-blue.css \
|
||||||
|
${documentation-highlighter}/loader.js
|
||||||
|
|
||||||
|
substituteInPlace ./options.md \
|
||||||
|
--replace \
|
||||||
|
'@OPTIONS_JSON@' \
|
||||||
|
${home-manager-options.home-manager}/share/doc/nixos/options.json
|
||||||
|
|
||||||
|
substituteInPlace ./nixos-options.md \
|
||||||
|
--replace \
|
||||||
|
'@OPTIONS_JSON@' \
|
||||||
|
${home-manager-options.nixos}/share/doc/nixos/options.json
|
||||||
|
|
||||||
|
substituteInPlace ./nix-darwin-options.md \
|
||||||
|
--replace \
|
||||||
|
'@OPTIONS_JSON@' \
|
||||||
|
${home-manager-options.nix-darwin}/share/doc/nixos/options.json
|
||||||
|
cp -t out/highlightjs ${nmd}/static/highlightjs/tomorrow-night.min.css
|
||||||
|
cp ${./highlight-style.css} out/highlightjs/highlight-style.css
|
||||||
|
|
||||||
|
nixos-render-docs manual html \
|
||||||
|
--manpage-urls ./manpage-urls.json \
|
||||||
|
--revision ${lib.trivial.revisionWithDefault revision} \
|
||||||
|
--stylesheet ${nmd}/static/style.css \
|
||||||
|
--stylesheet $out/share/doc/home-manager/highlightjs/tomorrow-night.min.css \
|
||||||
|
--stylesheet $out/share/doc/home-manager/highlightjs/highlight-style.css \
|
||||||
|
--script $out/share/doc/home-manager/highlightjs/highlight.pack.js \
|
||||||
|
--script $out/share/doc/home-manager/highlightjs/loader.js \
|
||||||
|
--toc-depth 1 \
|
||||||
|
--section-toc-depth 1 \
|
||||||
|
manual.md \
|
||||||
|
out/index.xhtml
|
||||||
|
'';
|
||||||
|
|
||||||
|
installPhase = ''
|
||||||
|
dest="$out/${outputPath}"
|
||||||
|
mkdir -p "$(dirname "$dest")"
|
||||||
|
mv out "$dest"
|
||||||
|
|
||||||
|
mkdir -p $out/nix-support/
|
||||||
|
echo "doc manual $dest index.html" >> $out/nix-support/hydra-build-products
|
||||||
|
'';
|
||||||
|
}
|
||||||
400
docs/home-manager.1
Normal file
400
docs/home-manager.1
Normal file
|
|
@ -0,0 +1,400 @@
|
||||||
|
.Dd January 1, 1980
|
||||||
|
.Dt home-manager 1
|
||||||
|
.Os Home Manager
|
||||||
|
.\" disable hyphenation
|
||||||
|
.nh
|
||||||
|
.\" disable justification (adjust text to left margin only)
|
||||||
|
.ad l
|
||||||
|
.\" enable line breaks after slashes
|
||||||
|
.cflags 4 /
|
||||||
|
.Sh NAME
|
||||||
|
.Nm home-manager
|
||||||
|
.Nd reconfigure a user environment
|
||||||
|
.
|
||||||
|
.
|
||||||
|
.
|
||||||
|
.Sh SYNOPSIS
|
||||||
|
.Nm home-manager
|
||||||
|
.Bro
|
||||||
|
.Cm build
|
||||||
|
.Cm | init Op Fl -switch Ar dir
|
||||||
|
.Cm | instantiate
|
||||||
|
.Cm | edit
|
||||||
|
.Cm | expire-generations Ar timestamp
|
||||||
|
.Cm | generations
|
||||||
|
.Cm | help
|
||||||
|
.Cm | news
|
||||||
|
.Cm | option Ar option.name
|
||||||
|
.Cm | packages
|
||||||
|
.Cm | remove-generations Ar ID \&...
|
||||||
|
.Cm | uninstall
|
||||||
|
.Brc
|
||||||
|
.Op Fl A Ar attrPath
|
||||||
|
.Op Fl I Ar path
|
||||||
|
.Op Fl -flake Ar flake-uri
|
||||||
|
.Op Fl b Ar ext
|
||||||
|
.Op Bro Fl f | Fl -file Brc Ar path
|
||||||
|
.Op Bro Fl h | Fl -help Brc
|
||||||
|
.Op Fl -version
|
||||||
|
.Op Bro Fl n | Fl -dry-run Brc
|
||||||
|
.Op Fl -option Ar name Ar value
|
||||||
|
.Op Fl -cores Ar number
|
||||||
|
.Op Bro Fl j | Fl -max-jobs Brc Ar number
|
||||||
|
.Op Fl -option
|
||||||
|
.Op Fl -impure
|
||||||
|
.Op Fl -keep-failed
|
||||||
|
.Op Fl -keep-going
|
||||||
|
.Op Bro Fl L | Fl -print-build-logs Brc
|
||||||
|
.Op Fl -show-trace
|
||||||
|
.Op Fl -(no-)substitute
|
||||||
|
.Op Fl -no-out-link
|
||||||
|
.Op Fl -refresh
|
||||||
|
.Op Bro Fl v | Fl -verbose Brc
|
||||||
|
.
|
||||||
|
.Sh DESCRIPTION
|
||||||
|
.Pp
|
||||||
|
This command updates the user environment so that it corresponds to the configuration specified in
|
||||||
|
$XDG_CONFIG_HOME/home-manager/home.nix
|
||||||
|
or
|
||||||
|
$XDG_CONFIG_HOME/home-manager/flake.nix.
|
||||||
|
.Pp
|
||||||
|
All operations using this tool expects a sub-command that indicates the operation to perform. It must be one of
|
||||||
|
.Pp
|
||||||
|
.Bl -tag -width Ds
|
||||||
|
|
||||||
|
.It Cm build
|
||||||
|
.RS 4
|
||||||
|
Build configuration into a result directory.
|
||||||
|
.RE
|
||||||
|
|
||||||
|
.It Cm init Op Fl -switch Op Ar dir
|
||||||
|
.RS 14
|
||||||
|
Generates an initial home.nix file for the current user. If Nix flakes are
|
||||||
|
enabled, then this command also generates a flake.nix file.
|
||||||
|
.sp
|
||||||
|
If a path
|
||||||
|
.Ar dir
|
||||||
|
is given then the configuration will be generated in that directory. Otherwise, the configuration will be generated in
|
||||||
|
~/.config/home-manager. The output directory will be created if it does not exist.
|
||||||
|
.sp
|
||||||
|
If the
|
||||||
|
.Fl -switch
|
||||||
|
option is given, then the generated configuration is activated.
|
||||||
|
.sp
|
||||||
|
Note, this command will not overwrite any existing files. It is therefore safe to initialize a configuration, edit it, and then re-run the
|
||||||
|
.Cm init
|
||||||
|
command with
|
||||||
|
.Fl -switch
|
||||||
|
enabled to activate the configuration.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm instantiate
|
||||||
|
.RS 15
|
||||||
|
Instantiate the configuration and print the resulting derivation\&.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm edit
|
||||||
|
.RS 16
|
||||||
|
Open the home configuration using the editor indicated by \fBEDITOR\fR\&.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm expire-generations Ar timestamp
|
||||||
|
.RS 4
|
||||||
|
Remove generations older than
|
||||||
|
.Ar timestamp
|
||||||
|
where
|
||||||
|
.Ar timestamp
|
||||||
|
is interpreted as in the
|
||||||
|
.Fl d
|
||||||
|
argument of the
|
||||||
|
\fBdate\fR(1)
|
||||||
|
tool. For example
|
||||||
|
-30 days or 2018-01-01.
|
||||||
|
.RE
|
||||||
|
.PP
|
||||||
|
|
||||||
|
.It Cm generations
|
||||||
|
.RS 4
|
||||||
|
List all home environment generations\&.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm help
|
||||||
|
.RS 4
|
||||||
|
Print tool help.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm news
|
||||||
|
.RS 4
|
||||||
|
Show news entries in a pager.
|
||||||
|
.RE
|
||||||
|
.PP
|
||||||
|
|
||||||
|
.It Cm option Ar option.name
|
||||||
|
.RS 4
|
||||||
|
Inspect the given option name in the home configuration, like
|
||||||
|
\fBnixos-option\fR(8)\&.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm packages
|
||||||
|
.RS 4
|
||||||
|
List all packages installed in home-manager-path.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm remove-generations Ar ID \&...
|
||||||
|
.RS 4
|
||||||
|
Remove indicated generations. Use the
|
||||||
|
.Cm generations
|
||||||
|
sub-command to find suitable generation numbers.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm switch
|
||||||
|
.RS 4
|
||||||
|
Build and activate the configuration\&.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm uninstall
|
||||||
|
.RS 4
|
||||||
|
Remove Home Manager from the user environment\&. This will
|
||||||
|
.sp
|
||||||
|
.RE
|
||||||
|
.RS 4
|
||||||
|
.Bl -bullet
|
||||||
|
.It
|
||||||
|
remove all managed files from the home directory,
|
||||||
|
.RE
|
||||||
|
.sp
|
||||||
|
.RS 4
|
||||||
|
.It
|
||||||
|
remove packages installed through Home Manager from the user profile, and
|
||||||
|
.RE
|
||||||
|
.sp
|
||||||
|
.RS 4
|
||||||
|
.It
|
||||||
|
remove all Home Manager generations and make them available for immediate garbage collection\&.
|
||||||
|
.RE
|
||||||
|
.El
|
||||||
|
.sp
|
||||||
|
.RE
|
||||||
|
.El
|
||||||
|
.
|
||||||
|
.Sh OPTIONS
|
||||||
|
.Pp
|
||||||
|
The tool accepts the options
|
||||||
|
.Pp
|
||||||
|
.Bl -tag -width Ds
|
||||||
|
.It Cm Fl A Ar attrPath
|
||||||
|
.RS 4
|
||||||
|
Optional attribute that selects a configuration expression in the configuration file. That is, if
|
||||||
|
home.nix contains
|
||||||
|
.sp
|
||||||
|
.if n \{\
|
||||||
|
.RS 4
|
||||||
|
.\}
|
||||||
|
.nf
|
||||||
|
{
|
||||||
|
joe\-at\-work = {pkgs, \&.\&.\&.}: { home\&.packages = [ pkgs\&.fortune ]; };
|
||||||
|
joe\-at\-home = {pkgs, \&.\&.\&.}: { home\&.packages = [ pkgs\&.cowsay ]; };
|
||||||
|
}
|
||||||
|
.fi
|
||||||
|
.if n \{\
|
||||||
|
.RE
|
||||||
|
.\}
|
||||||
|
.sp
|
||||||
|
then the command
|
||||||
|
\fBhome\-manager switch \-A joe\-at\-work\fR
|
||||||
|
will activate the profile containing the fortune program\&.
|
||||||
|
.RE
|
||||||
|
.PP
|
||||||
|
.It Cm Fl I Ar path
|
||||||
|
.RS 4
|
||||||
|
Add a path to the Nix expression search path. For example, to build a Home Manager profile using a specific Nixpkgs run
|
||||||
|
.Cm home-manager Fl I Ar nixpkgs=/absolute/path/to/nixpkgs build.
|
||||||
|
By default
|
||||||
|
.Ar <nixpkgs>
|
||||||
|
is used.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm Fl -flake Ar flake-uri[#name]
|
||||||
|
.RS 4
|
||||||
|
Build Home Manager configuration from the flake, which must contain the output homeConfigurations.name. If no name is specified it will first try username@hostname and then username.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm Fl b Ar extension
|
||||||
|
.RS 4
|
||||||
|
Enable automatic resolution of collisions between unmanaged and managed files\&. The name of the original file will be suffixed by the given extension\&. For example,
|
||||||
|
.sp
|
||||||
|
.if n \{\
|
||||||
|
.RS 4
|
||||||
|
.\}
|
||||||
|
.nf
|
||||||
|
$ \fBhome\-manager \-b bck switch\fR
|
||||||
|
.fi
|
||||||
|
.if n \{\
|
||||||
|
.RE
|
||||||
|
.\}
|
||||||
|
.sp
|
||||||
|
will cause a colliding file
|
||||||
|
~/\&.config/foo\&.conf
|
||||||
|
to be moved to
|
||||||
|
~/\&.config/foo\&.conf\&.bck\&.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm Fl f Ar path, Fl -file Ar path
|
||||||
|
.RS 4
|
||||||
|
Indicates the path to the Home Manager configuration file. If not given,
|
||||||
|
$XDG_CONFIG_HOME/home-manager/home.nix
|
||||||
|
is used.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
.It Cm Fl h, Fl -help
|
||||||
|
.RS 4
|
||||||
|
Prints usage information for the
|
||||||
|
\fBhome\-manager\fR
|
||||||
|
tool.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm Fl -version
|
||||||
|
.RS 4
|
||||||
|
Prints the version number of the
|
||||||
|
\fBhome\-manager\fR
|
||||||
|
tool.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
.It Cm Fl n, Fl -dry-run
|
||||||
|
.RS 4
|
||||||
|
Perform a dry-run of the given operation, only prints what actions would be taken.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm Fl -option Ar name Ar value
|
||||||
|
.RS 4
|
||||||
|
Passed on to
|
||||||
|
\fBnix-build\fR(1)\&.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm Fl -cores Ar number
|
||||||
|
.RS 4
|
||||||
|
Passed on to
|
||||||
|
\fBnix-build\fR(1)\&.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm Fl j Ar number, Fl -max-jobs Ar number
|
||||||
|
.RS 4
|
||||||
|
Passed on to
|
||||||
|
\fBnix-build\fR(1)\&.
|
||||||
|
.RE
|
||||||
|
.\" TODO
|
||||||
|
.Pp
|
||||||
|
.It Cm Fl -debug
|
||||||
|
.RS 4
|
||||||
|
Passed on to
|
||||||
|
\fBnix-build\fR(1)\&.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
.It Cm Fl -impure
|
||||||
|
.RS 4
|
||||||
|
Passed on to
|
||||||
|
\fBnix-build\fR(1)\&.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm Fl -keep-failed
|
||||||
|
.RS 4
|
||||||
|
Passed on to
|
||||||
|
\fBnix-build\fR(1)\&.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm Fl -keep-going
|
||||||
|
.RS 4
|
||||||
|
Passed on to
|
||||||
|
\fBnix-build\fR(1)\&.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm Fl L, Fl -print-build-logs
|
||||||
|
.RS 4
|
||||||
|
Passed on to
|
||||||
|
\fBnix build\fR()
|
||||||
|
when building from a flake\&.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm Fl -show-trace
|
||||||
|
.RS 4
|
||||||
|
Passed on to
|
||||||
|
\fBnix-build\fR(1)\&.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm Fl -(no-)substitute
|
||||||
|
.RS 4
|
||||||
|
Passed on to
|
||||||
|
\fBnix-build\fR(1)\&.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm Fl -no-out-link
|
||||||
|
.RS 4
|
||||||
|
Passed on to
|
||||||
|
\fBnix-build\fR(1)
|
||||||
|
when running
|
||||||
|
\fBhome\-manager build\fR\&.
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm Fl -refresh
|
||||||
|
.RS 4
|
||||||
|
Passed on to
|
||||||
|
\fBnix-build\fR(1)
|
||||||
|
.RE
|
||||||
|
.Pp
|
||||||
|
|
||||||
|
.It Cm Fl v, Fl -verbose
|
||||||
|
.RS 4
|
||||||
|
Activates verbose output\&.
|
||||||
|
.RE
|
||||||
|
.El
|
||||||
|
|
||||||
|
.Sh FILES
|
||||||
|
.Pp
|
||||||
|
$XDG_DATA_HOME/home\-manager/news\-read\-ids
|
||||||
|
.RS 4
|
||||||
|
Identifiers of news items that have been shown\&. Can be deleted to reset the read news indicator\&.
|
||||||
|
.RE
|
||||||
|
|
||||||
|
.Sh BUGS
|
||||||
|
.Pp
|
||||||
|
Please report any bugs on the
|
||||||
|
\m[blue]\fBproject issue tracker\fR\m[]\&.
|
||||||
|
|
||||||
|
.Sh SEE ALSO
|
||||||
|
.Pp
|
||||||
|
\fBhome-configuration.nix\fR(5)
|
||||||
|
|
||||||
|
.Sh AUTHOR
|
||||||
|
.Pp
|
||||||
|
\fBHome Manager contributors\fR
|
||||||
|
.RS 4
|
||||||
|
Author.
|
||||||
|
.RE
|
||||||
|
|
||||||
|
.Sh COPYRIGHT
|
||||||
|
.br
|
||||||
|
Copyright \(co 2017\(en2022 Home Manager contributors
|
||||||
|
.br
|
||||||
36
docs/html-open-tool.nix
Normal file
36
docs/html-open-tool.nix
Normal file
|
|
@ -0,0 +1,36 @@
|
||||||
|
{ writeShellScriptBin, makeDesktopItem, symlinkJoin }:
|
||||||
|
{ html, pathName ? "home-manager", projectName ? pathName
|
||||||
|
, name ? "${pathName}-help" }:
|
||||||
|
let
|
||||||
|
helpScript = writeShellScriptBin name ''
|
||||||
|
set -euo pipefail
|
||||||
|
|
||||||
|
if [[ ! -v BROWSER || -z $BROWSER ]]; then
|
||||||
|
for candidate in xdg-open open w3m; do
|
||||||
|
BROWSER="$(type -P $candidate || true)"
|
||||||
|
if [[ -x $BROWSER ]]; then
|
||||||
|
break;
|
||||||
|
fi
|
||||||
|
done
|
||||||
|
fi
|
||||||
|
|
||||||
|
if [[ ! -v BROWSER || -z $BROWSER ]]; then
|
||||||
|
echo "$0: unable to start a web browser; please set \$BROWSER"
|
||||||
|
exit 1
|
||||||
|
else
|
||||||
|
exec "$BROWSER" "${html}/share/doc/${pathName}/index.xhtml"
|
||||||
|
fi
|
||||||
|
'';
|
||||||
|
|
||||||
|
desktopItem = makeDesktopItem {
|
||||||
|
name = "${pathName}-manual";
|
||||||
|
desktopName = "${projectName} Manual";
|
||||||
|
genericName = "View ${projectName} documentation in a web browser";
|
||||||
|
icon = "nix-snowflake";
|
||||||
|
exec = "${helpScript}/bin/${name}";
|
||||||
|
categories = [ "System" ];
|
||||||
|
};
|
||||||
|
in symlinkJoin {
|
||||||
|
inherit name;
|
||||||
|
paths = [ helpScript desktopItem ];
|
||||||
|
}
|
||||||
|
|
@ -1,355 +0,0 @@
|
||||||
[[ch-installation]]
|
|
||||||
== Installing Home Manager
|
|
||||||
|
|
||||||
:nix-darwin: https://github.com/LnL7/nix-darwin/
|
|
||||||
:nixos-wiki-flakes: https://nixos.wiki/wiki/Flakes
|
|
||||||
|
|
||||||
Home Manager can be used in three primary ways:
|
|
||||||
|
|
||||||
1. Using the standalone `home-manager` tool. For platforms other than
|
|
||||||
NixOS and Darwin, this is the only available choice. It is also
|
|
||||||
recommended for people on NixOS or Darwin that want to manage their
|
|
||||||
home directory independently of the system as a whole. See
|
|
||||||
<<sec-install-standalone>> for instructions on how to perform this
|
|
||||||
installation.
|
|
||||||
|
|
||||||
2. As a module within a NixOS system configuration. This allows the
|
|
||||||
user profiles to be built together with the system when running
|
|
||||||
`nixos-rebuild`. See <<sec-install-nixos-module>> for a description of
|
|
||||||
this setup.
|
|
||||||
|
|
||||||
3. As a module within a {nix-darwin}[nix-darwin] system configuration.
|
|
||||||
This allows the user profiles to be built together with the system
|
|
||||||
when running `darwin-rebuild`. See <<sec-install-nix-darwin-module>>
|
|
||||||
for a description of this setup.
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
In this chapter we describe how to install Home Manager in the
|
|
||||||
standard way using channels. If you prefer to use
|
|
||||||
{nixos-wiki-flakes}[Nix Flakes] then please see the instructions in
|
|
||||||
<<ch-nix-flakes>>.
|
|
||||||
|
|
||||||
[[sec-install-standalone]]
|
|
||||||
=== Standalone installation
|
|
||||||
|
|
||||||
:nix-allowed-users: https://nixos.org/nix/manual/#conf-allowed-users
|
|
||||||
:nixos-allowed-users: https://nixos.org/manual/nixos/stable/options.html#opt-nix.settings.allowed-users
|
|
||||||
:bash: https://www.gnu.org/software/bash/
|
|
||||||
:zsh: http://zsh.sourceforge.net/
|
|
||||||
:fish: https://fishshell.com
|
|
||||||
:plugin-foreign-env: https://github.com/oh-my-fish/plugin-foreign-env
|
|
||||||
:babelfish: https://github.com/bouk/babelfish
|
|
||||||
|
|
||||||
1. Make sure you have a working Nix installation. Specifically, make
|
|
||||||
sure that your user is able to build and install Nix packages. For
|
|
||||||
example, you should be able to successfully run a command like
|
|
||||||
`nix-instantiate '<nixpkgs>' -A hello` without having to switch to the
|
|
||||||
root user. For a multi-user install of Nix this means that your user
|
|
||||||
must be covered by the {nix-allowed-users}[`allowed-users`] Nix
|
|
||||||
option. On NixOS you can control this option using the
|
|
||||||
{nixos-allowed-users}[`nix.settings.allowed-users`] system option.
|
|
||||||
|
|
||||||
2. Add the appropriate Home Manager channel. If you are following
|
|
||||||
Nixpkgs master or an unstable channel you can run
|
|
||||||
+
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ nix-channel --add https://github.com/nix-community/home-manager/archive/master.tar.gz home-manager
|
|
||||||
$ nix-channel --update
|
|
||||||
----
|
|
||||||
+
|
|
||||||
and if you follow a Nixpkgs version 23.11 channel you can run
|
|
||||||
+
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ nix-channel --add https://github.com/nix-community/home-manager/archive/release-23.11.tar.gz home-manager
|
|
||||||
$ nix-channel --update
|
|
||||||
----
|
|
||||||
|
|
||||||
3. Run the Home Manager installation command and create the first Home
|
|
||||||
Manager generation:
|
|
||||||
+
|
|
||||||
[source,console]
|
|
||||||
$ nix-shell '<home-manager>' -A install
|
|
||||||
+
|
|
||||||
Once finished, Home Manager should be active and available in your
|
|
||||||
user environment.
|
|
||||||
|
|
||||||
4. If you do not plan on having Home Manager manage your shell
|
|
||||||
configuration then you must source the
|
|
||||||
+
|
|
||||||
[source,bash]
|
|
||||||
$HOME/.nix-profile/etc/profile.d/hm-session-vars.sh
|
|
||||||
+
|
|
||||||
file in your shell configuration. Alternatively source
|
|
||||||
+
|
|
||||||
[source,bash]
|
|
||||||
/etc/profiles/per-user/$USER/etc/profile.d/hm-session-vars.sh
|
|
||||||
+
|
|
||||||
when managing home configuration together with system configuration.
|
|
||||||
+
|
|
||||||
This file can be sourced directly by POSIX.2-like shells such as
|
|
||||||
{bash}[Bash] or {zsh}[Z shell]. {fish}[Fish] users can use utilities
|
|
||||||
such as {plugin-foreign-env}[foreign-env] or {babelfish}[babelfish].
|
|
||||||
+
|
|
||||||
For example, if you use Bash then add
|
|
||||||
+
|
|
||||||
[source,bash]
|
|
||||||
----
|
|
||||||
. "$HOME/.nix-profile/etc/profile.d/hm-session-vars.sh"
|
|
||||||
----
|
|
||||||
+
|
|
||||||
to your `~/.profile` file.
|
|
||||||
|
|
||||||
If instead of using channels you want to run Home Manager from a Git
|
|
||||||
checkout of the repository then you can use the
|
|
||||||
<<opt-programs.home-manager.path>> option to specify the absolute path
|
|
||||||
to the repository.
|
|
||||||
|
|
||||||
Once installed you can see <<ch-usage>> for a more detailed
|
|
||||||
description of Home Manager and how to use it.
|
|
||||||
|
|
||||||
[[sec-install-nixos-module]]
|
|
||||||
=== NixOS module
|
|
||||||
|
|
||||||
Home Manager provides a NixOS module that allows you to prepare user
|
|
||||||
environments directly from the system configuration file, which often
|
|
||||||
is more convenient than using the `home-manager` tool. It also opens
|
|
||||||
up additional possibilities, for example, to automatically configure
|
|
||||||
user environments in NixOS declarative containers or on systems
|
|
||||||
deployed through NixOps.
|
|
||||||
|
|
||||||
To make the NixOS module available for use you must `import` it into
|
|
||||||
your system configuration. This is most conveniently done by adding a
|
|
||||||
Home Manager channel to the root user. For example, if you are
|
|
||||||
following Nixpkgs master or an unstable channel, you can run
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ sudo nix-channel --add https://github.com/nix-community/home-manager/archive/master.tar.gz home-manager
|
|
||||||
$ sudo nix-channel --update
|
|
||||||
----
|
|
||||||
|
|
||||||
and if you follow a Nixpkgs version 23.11 channel, you can run
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ sudo nix-channel --add https://github.com/nix-community/home-manager/archive/release-23.11.tar.gz home-manager
|
|
||||||
$ sudo nix-channel --update
|
|
||||||
----
|
|
||||||
|
|
||||||
It is then possible to add
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
imports = [ <home-manager/nixos> ];
|
|
||||||
|
|
||||||
to your system `configuration.nix` file, which will introduce a new
|
|
||||||
NixOS option called `home-manager.users` whose type is an attribute
|
|
||||||
set that maps user names to Home Manager configurations.
|
|
||||||
|
|
||||||
For example, a NixOS configuration may include the lines
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
users.users.eve.isNormalUser = true;
|
|
||||||
home-manager.users.eve = { pkgs, ... }: {
|
|
||||||
home.packages = [ pkgs.atool pkgs.httpie ];
|
|
||||||
programs.bash.enable = true;
|
|
||||||
|
|
||||||
# The state version is required and should stay at the version you
|
|
||||||
# originally installed.
|
|
||||||
home.stateVersion = "23.11";
|
|
||||||
};
|
|
||||||
----
|
|
||||||
|
|
||||||
and after a `sudo nixos-rebuild switch` the user eve's environment should
|
|
||||||
include a basic Bash configuration and the packages atool and httpie.
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
====
|
|
||||||
If `nixos-rebuild switch` does not result in the environment you expect,
|
|
||||||
you can take a look at the output of the Home Manager activation script output using
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
$ systemctl status "home-manager-$USER.service"
|
|
||||||
====
|
|
||||||
|
|
||||||
If you do not plan on having Home Manager manage your shell
|
|
||||||
configuration then you must add either
|
|
||||||
|
|
||||||
[source,bash]
|
|
||||||
----
|
|
||||||
. "$HOME/.nix-profile/etc/profile.d/hm-session-vars.sh"
|
|
||||||
----
|
|
||||||
|
|
||||||
or
|
|
||||||
|
|
||||||
[source,bash]
|
|
||||||
----
|
|
||||||
. "/etc/profiles/per-user/$USER/etc/profile.d/hm-session-vars.sh"
|
|
||||||
----
|
|
||||||
|
|
||||||
to your shell configuration, depending on whether
|
|
||||||
<<nixos-opt-home-manager.useUserPackages>> is enabled. This file can
|
|
||||||
be sourced directly by POSIX.2-like shells such as {bash}[Bash] or
|
|
||||||
{zsh}[Z shell]. {fish}[Fish] users can use utilities such as
|
|
||||||
{plugin-foreign-env}[foreign-env] or {babelfish}[babelfish].
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
====
|
|
||||||
By default packages will be installed to `$HOME/.nix-profile` but they
|
|
||||||
can be installed to `/etc/profiles` if
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
home-manager.useUserPackages = true;
|
|
||||||
|
|
||||||
is added to the system configuration. This is necessary if, for
|
|
||||||
example, you wish to use `nixos-rebuild build-vm`. This option may
|
|
||||||
become the default value in the future.
|
|
||||||
====
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
====
|
|
||||||
By default, Home Manager uses a private `pkgs` instance that is
|
|
||||||
configured via the `home-manager.users.<name>.nixpkgs` options. To
|
|
||||||
instead use the global `pkgs` that is configured via the system level
|
|
||||||
`nixpkgs` options, set
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
home-manager.useGlobalPkgs = true;
|
|
||||||
|
|
||||||
This saves an extra Nixpkgs evaluation, adds consistency, and removes
|
|
||||||
the dependency on `NIX_PATH`, which is otherwise used for importing
|
|
||||||
Nixpkgs.
|
|
||||||
====
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
====
|
|
||||||
Home Manager will pass `osConfig` as a module argument to any modules
|
|
||||||
you create. This contains the system's NixOS configuration.
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
{ lib, pkgs, osConfig, ... }:
|
|
||||||
====
|
|
||||||
|
|
||||||
Once installed you can see <<ch-usage>> for a more detailed
|
|
||||||
description of Home Manager and how to use it.
|
|
||||||
|
|
||||||
[[sec-install-nix-darwin-module]]
|
|
||||||
=== nix-darwin module
|
|
||||||
|
|
||||||
Home Manager provides a module that allows you to prepare user
|
|
||||||
environments directly from the {nix-darwin}[nix-darwin] configuration
|
|
||||||
file, which often is more convenient than using the `home-manager`
|
|
||||||
tool.
|
|
||||||
|
|
||||||
To make the NixOS module available for use you must `import` it into
|
|
||||||
your system configuration. This is most conveniently done by adding a
|
|
||||||
Home Manager channel. For example, if you are following Nixpkgs master
|
|
||||||
or an unstable channel, you can run
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ nix-channel --add https://github.com/nix-community/home-manager/archive/master.tar.gz home-manager
|
|
||||||
$ nix-channel --update
|
|
||||||
----
|
|
||||||
|
|
||||||
and if you follow a Nixpkgs version 23.11 channel, you can run
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ nix-channel --add https://github.com/nix-community/home-manager/archive/release-23.11.tar.gz home-manager
|
|
||||||
$ nix-channel --update
|
|
||||||
----
|
|
||||||
|
|
||||||
It is then possible to add
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
imports = [ <home-manager/nix-darwin> ];
|
|
||||||
|
|
||||||
to your nix-darwin `configuration.nix` file, which will introduce a
|
|
||||||
new NixOS option called `home-manager` whose type is an attribute set
|
|
||||||
that maps user names to Home Manager configurations.
|
|
||||||
|
|
||||||
For example, a nix-darwin configuration may include the lines
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
users.users.eve = {
|
|
||||||
name = "eve";
|
|
||||||
home = "/Users/eve";
|
|
||||||
}
|
|
||||||
home-manager.users.eve = { pkgs, ... }: {
|
|
||||||
home.packages = [ pkgs.atool pkgs.httpie ];
|
|
||||||
programs.bash.enable = true;
|
|
||||||
|
|
||||||
# The state version is required and should stay at the version you
|
|
||||||
# originally installed.
|
|
||||||
home.stateVersion = "23.11";
|
|
||||||
};
|
|
||||||
----
|
|
||||||
|
|
||||||
and after a `darwin-rebuild switch` the user eve's environment
|
|
||||||
should include a basic Bash configuration and the packages atool and
|
|
||||||
httpie.
|
|
||||||
|
|
||||||
If you do not plan on having Home Manager manage your shell
|
|
||||||
configuration then you must add either
|
|
||||||
|
|
||||||
[source,bash]
|
|
||||||
----
|
|
||||||
. "$HOME/.nix-profile/etc/profile.d/hm-session-vars.sh"
|
|
||||||
----
|
|
||||||
|
|
||||||
or
|
|
||||||
|
|
||||||
[source,bash]
|
|
||||||
----
|
|
||||||
. "/etc/profiles/per-user/$USER/etc/profile.d/hm-session-vars.sh"
|
|
||||||
----
|
|
||||||
|
|
||||||
to your shell configuration, depending on whether
|
|
||||||
<<nix-darwin-opt-home-manager.useUserPackages>> is enabled. This file
|
|
||||||
can be sourced directly by POSIX.2-like shells such as {bash}[Bash] or
|
|
||||||
{zsh}[Z shell]. {fish}[Fish] users can use utilities such as
|
|
||||||
{plugin-foreign-env}[foreign-env] or {babelfish}[babelfish].
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
====
|
|
||||||
By default user packages will not be ignored in favor of
|
|
||||||
`environment.systemPackages`, but they will be installed to
|
|
||||||
`/etc/profiles/per-user/$USERNAME` if
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
home-manager.useUserPackages = true;
|
|
||||||
|
|
||||||
is added to the nix-darwin configuration. This option may become the
|
|
||||||
default value in the future.
|
|
||||||
====
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
====
|
|
||||||
By default, Home Manager uses a private `pkgs` instance that is
|
|
||||||
configured via the `home-manager.users.<name>.nixpkgs` options. To
|
|
||||||
instead use the global `pkgs` that is configured via the system level
|
|
||||||
`nixpkgs` options, set
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
home-manager.useGlobalPkgs = true;
|
|
||||||
|
|
||||||
This saves an extra Nixpkgs evaluation, adds consistency, and removes
|
|
||||||
the dependency on `NIX_PATH`, which is otherwise used for importing
|
|
||||||
Nixpkgs.
|
|
||||||
====
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
====
|
|
||||||
Home Manager will pass `osConfig` as a module argument to any modules
|
|
||||||
you create. This contains the system's nix-darwin configuration.
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
{ lib, pkgs, osConfig, ... }:
|
|
||||||
====
|
|
||||||
|
|
||||||
Once installed you can see <<ch-usage>> for a more detailed
|
|
||||||
description of Home Manager and how to use it.
|
|
||||||
|
|
@ -1,40 +0,0 @@
|
||||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
||||||
<refmeta>
|
|
||||||
<refentrytitle><filename>home-configuration.nix</filename></refentrytitle>
|
|
||||||
<manvolnum>5</manvolnum>
|
|
||||||
<refmiscinfo class="source">Home Manager</refmiscinfo>
|
|
||||||
<!-- <refmiscinfo class="version"><xi:include href="version.txt" parse="text"/></refmiscinfo> -->
|
|
||||||
</refmeta>
|
|
||||||
<refnamediv>
|
|
||||||
<refname><filename>home-configuration.nix</filename></refname>
|
|
||||||
<refpurpose>Home Manager configuration specification</refpurpose>
|
|
||||||
</refnamediv>
|
|
||||||
<refsection>
|
|
||||||
<title>Description</title>
|
|
||||||
<simpara>
|
|
||||||
The file <filename>~/.config/home-manager/home.nix</filename> contains the
|
|
||||||
declarative specification of your Home Manager configuration. The command
|
|
||||||
<command>home-manager</command> takes this file and realises the user
|
|
||||||
environment configuration specified therein.
|
|
||||||
</simpara>
|
|
||||||
</refsection>
|
|
||||||
<refsection>
|
|
||||||
<title>Options</title>
|
|
||||||
<para>
|
|
||||||
You can use the following options in
|
|
||||||
<filename>home-configuration.nix</filename>:
|
|
||||||
</para>
|
|
||||||
<xi:include href="./nmd-result/home-manager-options.xml" xpointer="home-manager-options" />
|
|
||||||
</refsection>
|
|
||||||
<refsection>
|
|
||||||
<title>See also</title>
|
|
||||||
<para>
|
|
||||||
<citerefentry>
|
|
||||||
<refentrytitle>home-manager</refentrytitle>
|
|
||||||
<manvolnum>1</manvolnum>
|
|
||||||
</citerefentry>
|
|
||||||
</para>
|
|
||||||
</refsection>
|
|
||||||
</refentry>
|
|
||||||
|
|
@ -1,713 +0,0 @@
|
||||||
<refentry xmlns="http://docbook.org/ns/docbook"
|
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
||||||
<refmeta>
|
|
||||||
<refentrytitle><command>home-manager</command>
|
|
||||||
</refentrytitle><manvolnum>1</manvolnum>
|
|
||||||
<refmiscinfo class="source">Home Manager</refmiscinfo>
|
|
||||||
</refmeta>
|
|
||||||
<refnamediv>
|
|
||||||
<refname><command>home-manager</command>
|
|
||||||
</refname><refpurpose>reconfigure a user environment</refpurpose>
|
|
||||||
</refnamediv>
|
|
||||||
<refsynopsisdiv>
|
|
||||||
<cmdsynopsis>
|
|
||||||
<command>home-manager</command> <group choice="req">
|
|
||||||
<arg choice="plain">
|
|
||||||
build
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
init <arg>--switch</arg> <arg><replaceable>dir</replaceable></arg>
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
instantiate
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
edit
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
expire-generations <replaceable>timestamp</replaceable>
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
generations
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
help
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
news
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
option <replaceable>option.name</replaceable>
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
packages
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
remove-generations <replaceable>ID …</replaceable>
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
switch
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
uninstall
|
|
||||||
</arg>
|
|
||||||
</group>
|
|
||||||
<sbr />
|
|
||||||
<arg>
|
|
||||||
-A <replaceable>attrPath</replaceable>
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
-I <replaceable>path</replaceable>
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
--flake <replaceable>flake-uri</replaceable>
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
-b <replaceable>ext</replaceable>
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
<group choice="req">
|
|
||||||
<arg choice="plain">
|
|
||||||
-f
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
--file
|
|
||||||
</arg>
|
|
||||||
</group> <replaceable>path</replaceable>
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
<group choice="req">
|
|
||||||
<arg choice="plain">
|
|
||||||
-h
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
--help
|
|
||||||
</arg>
|
|
||||||
</group>
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
--version
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
<group choice="req">
|
|
||||||
<arg choice="plain">
|
|
||||||
-n
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
--dry-run
|
|
||||||
</arg>
|
|
||||||
</group>
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
--option <replaceable>name</replaceable> <replaceable>value</replaceable>
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
--cores <replaceable>number</replaceable>
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
<group choice="req">
|
|
||||||
<arg choice="plain">
|
|
||||||
-j
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
--max-jobs
|
|
||||||
</arg>
|
|
||||||
</group>
|
|
||||||
<replaceable>number</replaceable>
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
--debug
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
--impure
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
--keep-failed
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
--keep-going
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
<group choice="req">
|
|
||||||
<arg choice="plain">
|
|
||||||
-L
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
--print-build-logs
|
|
||||||
</arg>
|
|
||||||
</group>
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
--show-trace
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
--(no-)substitute
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
--no-out-link
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
--refresh
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg>
|
|
||||||
<group choice="req">
|
|
||||||
<arg choice="plain">
|
|
||||||
-v
|
|
||||||
</arg>
|
|
||||||
|
|
||||||
<arg choice="plain">
|
|
||||||
--verbose
|
|
||||||
</arg>
|
|
||||||
</group>
|
|
||||||
</arg>
|
|
||||||
</cmdsynopsis>
|
|
||||||
</refsynopsisdiv>
|
|
||||||
<refsection>
|
|
||||||
<title>Description</title>
|
|
||||||
<para>
|
|
||||||
This command updates the user environment so that it corresponds to the
|
|
||||||
configuration specified in
|
|
||||||
<filename>$XDG_CONFIG_HOME/home-manager/home.nix</filename> or
|
|
||||||
<filename>$XDG_CONFIG_HOME/home-manager/flake.nix</filename>.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
All operations using this tool expects a sub-command that indicates the
|
|
||||||
operation to perform. It must be one of
|
|
||||||
<variablelist>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>build</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Build configuration into a <filename>result</filename> directory.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>init</option> [<option>--switch</option>] [<replaceable>dir</replaceable>]
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<simpara>
|
|
||||||
Generates an initial <filename>home.nix</filename> file for the
|
|
||||||
current user. If Nix flakes are enabled, then this command also
|
|
||||||
generates a <filename>flake.nix</filename> file.
|
|
||||||
</simpara>
|
|
||||||
<simpara>
|
|
||||||
If a path <replaceable>dir</replaceable> is given then the
|
|
||||||
configuration will be generated in that directory. Otherwise, the
|
|
||||||
configuration will be generated in
|
|
||||||
<filename>~/.config/home-manager</filename>. The output directory will
|
|
||||||
be created if it does not exist.
|
|
||||||
</simpara>
|
|
||||||
<simpara>
|
|
||||||
If the <option>--switch</option> option is given, then the generated
|
|
||||||
configuration is activated.
|
|
||||||
</simpara>
|
|
||||||
<simpara>
|
|
||||||
Note, this command will not overwrite any existing files. It is
|
|
||||||
therefore safe to initialize a configuration, edit it, and then re-run
|
|
||||||
the <option>init</option> command with <option>--switch</option>
|
|
||||||
enabled to activate the configuration.
|
|
||||||
</simpara>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>instantiate</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Instantiate the configuration and print the resulting derivation.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>edit</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Open the home configuration using the editor indicated by
|
|
||||||
<envar>EDITOR</envar>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>expire-generations <replaceable>timestamp</replaceable></option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Remove generations older than <replaceable>timestamp</replaceable> where
|
|
||||||
<replaceable>timestamp</replaceable> is interpreted as in the
|
|
||||||
<option>-d</option> argument of the <citerefentry>
|
|
||||||
<refentrytitle>date</refentrytitle>
|
|
||||||
<manvolnum>1</manvolnum> </citerefentry> tool. For example <literal>-30
|
|
||||||
days</literal> or <literal>2018-01-01</literal>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>generations</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
List all home environment generations.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>help</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Print tool help.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>news</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Show news entries in a pager.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>option <replaceable>option.name</replaceable></option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Inspect the given option name in the home configuration, like <citerefentry>
|
|
||||||
<refentrytitle>nixos-option</refentrytitle>
|
|
||||||
<manvolnum>8</manvolnum> </citerefentry>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>packages</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
List all packages installed in <varname>home-manager-path</varname>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>remove-generations <replaceable>ID …</replaceable></option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Remove indicated generations. Use the <option>generations</option>
|
|
||||||
sub-command to find suitable generation numbers.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>switch</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Build and activate the configuration.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>uninstall</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Remove Home Manager from the user environment. This will
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
remove all managed files from the home directory,
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
remove packages installed through Home Manager from the user profile,
|
|
||||||
and
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
remove all Home Manager generations and make them available
|
|
||||||
for immediate garbage collection.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
</variablelist>
|
|
||||||
</para>
|
|
||||||
</refsection>
|
|
||||||
<refsection>
|
|
||||||
<title>Options</title>
|
|
||||||
<para>
|
|
||||||
The tool accepts the options
|
|
||||||
</para>
|
|
||||||
<variablelist>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>-A <replaceable>attrPath</replaceable></option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Optional attribute that selects a configuration expression in the
|
|
||||||
configuration file. That is, if <filename>home.nix</filename> contains
|
|
||||||
<programlisting language="nix">
|
|
||||||
{
|
|
||||||
joe-at-work = {pkgs, ...}: { home.packages = [ pkgs.fortune ]; };
|
|
||||||
joe-at-home = {pkgs, ...}: { home.packages = [ pkgs.cowsay ]; };
|
|
||||||
}
|
|
||||||
</programlisting>
|
|
||||||
then the command <command>home-manager switch -A joe-at-work</command>
|
|
||||||
will activate the profile containing the fortune program.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>-I <replaceable>path</replaceable></option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Add a path to the Nix expression search path. For example, to build a
|
|
||||||
Home Manager profile using a specific Nixpkgs run <command>home-manager
|
|
||||||
-I nixpkgs=/absolute/path/to/nixpkgs build</command>. By default
|
|
||||||
<literal><nixpkgs></literal> is used.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>--flake <replaceable>flake-uri[#name]</replaceable></option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Build Home Manager configuration from the flake, which must contain the
|
|
||||||
output homeConfigurations.name. If no name is specified it will first try
|
|
||||||
username@hostname and then username.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>-b <replaceable>extension</replaceable></option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Enable automatic resolution of collisions between unmanaged and managed
|
|
||||||
files. The name of the original file will be suffixed by the given
|
|
||||||
extension. For example,
|
|
||||||
<screen>
|
|
||||||
<prompt>$</prompt> <userinput>home-manager -b bck switch</userinput>
|
|
||||||
</screen>
|
|
||||||
will cause a colliding file <filename>~/.config/foo.conf</filename> to be
|
|
||||||
moved to <filename>~/.config/foo.conf.bck</filename>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>-f <replaceable>path</replaceable></option>
|
|
||||||
</term>
|
|
||||||
<term>
|
|
||||||
<option>--file <replaceable>path</replaceable></option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Indicates the path to the Home Manager configuration file. If not given,
|
|
||||||
<filename>$XDG_CONFIG_HOME/home-manager/home.nix</filename> is used.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>-h</option>
|
|
||||||
</term>
|
|
||||||
<term>
|
|
||||||
<option>--help</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Prints usage information for the <command>home-manager</command> tool.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>--version</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Prints the version number of the <command>home-manager</command> tool.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>-n</option>
|
|
||||||
</term>
|
|
||||||
<term>
|
|
||||||
<option>--dry-run</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Perform a dry-run of the given operation, only prints what actions would
|
|
||||||
be taken.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>--option <replaceable>name</replaceable> <replaceable>value</replaceable></option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Passed on to <citerefentry>
|
|
||||||
<refentrytitle>nix-build</refentrytitle>
|
|
||||||
<manvolnum>1</manvolnum> </citerefentry>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>--cores <replaceable>number</replaceable></option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Passed on to <citerefentry>
|
|
||||||
<refentrytitle>nix-build</refentrytitle>
|
|
||||||
<manvolnum>1</manvolnum> </citerefentry>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>-j <replaceable>number</replaceable></option>
|
|
||||||
</term>
|
|
||||||
<term>
|
|
||||||
<option>--max-jobs <replaceable>number</replaceable></option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Passed on to <citerefentry>
|
|
||||||
<refentrytitle>nix-build</refentrytitle>
|
|
||||||
<manvolnum>1</manvolnum> </citerefentry>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>--debug</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Passed on to <citerefentry>
|
|
||||||
<refentrytitle>nix-build</refentrytitle>
|
|
||||||
<manvolnum>1</manvolnum> </citerefentry>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>--impure</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Passed on to <citerefentry>
|
|
||||||
<refentrytitle>nix-build</refentrytitle>
|
|
||||||
<manvolnum>1</manvolnum> </citerefentry>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>--keep-failed</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Passed on to <citerefentry>
|
|
||||||
<refentrytitle>nix-build</refentrytitle>
|
|
||||||
<manvolnum>1</manvolnum> </citerefentry>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>--keep-going</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Passed on to <citerefentry>
|
|
||||||
<refentrytitle>nix-build</refentrytitle>
|
|
||||||
<manvolnum>1</manvolnum> </citerefentry>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>-L</option>
|
|
||||||
</term>
|
|
||||||
<term>
|
|
||||||
<option>--print-build-logs</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Passed on to <citerefentry>
|
|
||||||
<refentrytitle>nix build</refentrytitle>
|
|
||||||
</citerefentry>
|
|
||||||
when building from a flake.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>--show-trace</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Passed on to <citerefentry>
|
|
||||||
<refentrytitle>nix-build</refentrytitle>
|
|
||||||
<manvolnum>1</manvolnum> </citerefentry>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>--(no-)substitute</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Passed on to <citerefentry>
|
|
||||||
<refentrytitle>nix-build</refentrytitle>
|
|
||||||
<manvolnum>1</manvolnum> </citerefentry>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>--no-out-link</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Passed on to <citerefentry>
|
|
||||||
<refentrytitle>nix-build</refentrytitle>
|
|
||||||
<manvolnum>1</manvolnum> </citerefentry>
|
|
||||||
when running <command>home-manager build</command>.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>--refresh</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Passed on to <citerefentry>
|
|
||||||
<refentrytitle>nix-build</refentrytitle>
|
|
||||||
<manvolnum>1</manvolnum> </citerefentry>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<option>-v</option>
|
|
||||||
</term>
|
|
||||||
<term>
|
|
||||||
<option>--verbose</option>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Activates verbose output.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
</variablelist>
|
|
||||||
</refsection>
|
|
||||||
<refsection>
|
|
||||||
<title>Files</title>
|
|
||||||
<variablelist>
|
|
||||||
<varlistentry>
|
|
||||||
<term>
|
|
||||||
<filename>$XDG_DATA_HOME/home-manager/news-read-ids</filename>
|
|
||||||
</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Identifiers of news items that have been shown. Can be deleted to reset
|
|
||||||
the read news indicator.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
</variablelist>
|
|
||||||
</refsection>
|
|
||||||
<refsection>
|
|
||||||
<title>Bugs</title>
|
|
||||||
<para>
|
|
||||||
Please report any bugs on the
|
|
||||||
<link
|
|
||||||
xlink:href="https://github.com/nix-community/home-manager/issues">project
|
|
||||||
issue tracker</link>.
|
|
||||||
</para>
|
|
||||||
</refsection>
|
|
||||||
<refsection>
|
|
||||||
<title>See also</title>
|
|
||||||
<para>
|
|
||||||
<citerefentry>
|
|
||||||
<refentrytitle>home-configuration.nix</refentrytitle>
|
|
||||||
<manvolnum>5</manvolnum> </citerefentry>
|
|
||||||
</para>
|
|
||||||
</refsection>
|
|
||||||
</refentry>
|
|
||||||
|
|
@ -1,12 +0,0 @@
|
||||||
<reference xmlns="http://docbook.org/ns/docbook"
|
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
||||||
<title>Home Manager Reference Pages</title>
|
|
||||||
<info>
|
|
||||||
<author><personname>Home Manager contributors</personname></author>
|
|
||||||
<copyright><year>2017–2022</year><holder>Home Manager contributors</holder>
|
|
||||||
</copyright>
|
|
||||||
</info>
|
|
||||||
<xi:include href="man-configuration.xml" />
|
|
||||||
<xi:include href="man-home-manager.xml" />
|
|
||||||
</reference>
|
|
||||||
|
|
@ -1,57 +0,0 @@
|
||||||
<book xmlns="http://docbook.org/ns/docbook"
|
|
||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
||||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
||||||
version="5.0"
|
|
||||||
xml:id="book-home-manager-manual">
|
|
||||||
<info>
|
|
||||||
<title>Home Manager Manual</title>
|
|
||||||
</info>
|
|
||||||
<preface>
|
|
||||||
<title>Preface</title>
|
|
||||||
<para>
|
|
||||||
This manual will eventually describe how to install, use, and extend Home
|
|
||||||
Manager.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
If you encounter problems then please reach out on the IRC channel
|
|
||||||
<link xlink:href="https://webchat.oftc.net/?channels=home-manager">#home-manager</link>
|
|
||||||
hosted by <link xlink:href="https://oftc.net/">OFTC</link>.
|
|
||||||
There is also a <link xlink:href="https://matrix.to/#/%23hm:rycee.net">Matrix room</link>,
|
|
||||||
which is bridged to the IRC channel.
|
|
||||||
If your problem is caused by a bug in Home Manager then it should
|
|
||||||
be reported on the
|
|
||||||
<link xlink:href="https://github.com/nix-community/home-manager/issues">Home Manager issue tracker</link>.
|
|
||||||
</para>
|
|
||||||
<note>
|
|
||||||
<para>
|
|
||||||
Commands prefixed with <literal>$ sudo</literal> have to be run as root, either
|
|
||||||
requiring to login as root user or temporarily switching to it using
|
|
||||||
<literal>sudo</literal> for example.
|
|
||||||
</para>
|
|
||||||
</note>
|
|
||||||
</preface>
|
|
||||||
<xi:include href="installation.xml" />
|
|
||||||
<xi:include href="usage.xml" />
|
|
||||||
<xi:include href="nix-flakes.xml" />
|
|
||||||
<xi:include href="writing-modules.xml" />
|
|
||||||
<xi:include href="contributing.xml" />
|
|
||||||
<xi:include href="3rd-party.xml" />
|
|
||||||
<xi:include href="faq.xml" />
|
|
||||||
<appendix xml:id="ch-options">
|
|
||||||
<title>Configuration Options</title>
|
|
||||||
<xi:include href="./nmd-result/home-manager-options.xml" xpointer="home-manager-options" />
|
|
||||||
</appendix>
|
|
||||||
<appendix xml:id="ch-nixos-options">
|
|
||||||
<title>NixOS Module Options</title>
|
|
||||||
<xi:include href="./nmd-result/nixos-options.xml" xpointer="nixos-options" />
|
|
||||||
</appendix>
|
|
||||||
<appendix xml:id="ch-nix-darwin-options">
|
|
||||||
<title>nix-darwin Module Options</title>
|
|
||||||
<xi:include href="./nmd-result/nix-darwin-options.xml" xpointer="nix-darwin-options" />
|
|
||||||
</appendix>
|
|
||||||
<appendix xml:id="ch-tools">
|
|
||||||
<title>Tools</title>
|
|
||||||
<xi:include href="./man-home-manager.xml" />
|
|
||||||
</appendix>
|
|
||||||
<xi:include href="./release-notes/release-notes.xml" />
|
|
||||||
</book>
|
|
||||||
14
docs/manual/3rd-party.md
Normal file
14
docs/manual/3rd-party.md
Normal file
|
|
@ -0,0 +1,14 @@
|
||||||
|
# Third-Party Tools and Extensions {#ch-3rd-party}
|
||||||
|
|
||||||
|
Here is a collection of tools and extensions that relate to Home
|
||||||
|
Manager. Note, these are maintained outside the regular Home Manager
|
||||||
|
flow so quality and support may vary wildly. If you encounter problems
|
||||||
|
then please raise them in the corresponding project, not as issues in
|
||||||
|
the Home Manager tracker.
|
||||||
|
|
||||||
|
If you have made something interesting related to Home Manager then you
|
||||||
|
are encouraged to create a PR that expands this chapter.
|
||||||
|
|
||||||
|
```{=include=} sections
|
||||||
|
3rd-party/collections.md
|
||||||
|
```
|
||||||
11
docs/manual/3rd-party/collections.md
vendored
Normal file
11
docs/manual/3rd-party/collections.md
vendored
Normal file
|
|
@ -0,0 +1,11 @@
|
||||||
|
# Module Collections {#sec-3rd-party-module-collections}
|
||||||
|
|
||||||
|
- [xhmm --- extra Home Manager
|
||||||
|
modules](https://github.com/schuelermine/xhmm)
|
||||||
|
|
||||||
|
A collection of modules maintained by Anselm Schüler.
|
||||||
|
|
||||||
|
- [Stylix --- System-wide colorscheming and
|
||||||
|
typography](https://github.com/danth/stylix/)
|
||||||
|
|
||||||
|
Configure your applications to get coherent color scheme and font.
|
||||||
27
docs/manual/contributing.md
Normal file
27
docs/manual/contributing.md
Normal file
|
|
@ -0,0 +1,27 @@
|
||||||
|
# Contributing {#ch-contributing}
|
||||||
|
|
||||||
|
Contributions to Home Manager are very welcome. To make the process as
|
||||||
|
smooth as possible for both you and the Home Manager maintainers we
|
||||||
|
provide some guidelines that we ask you to follow. See [Getting
|
||||||
|
started](#sec-contrib-getting-started) for information on how to set up
|
||||||
|
a suitable development environment and [Guidelines](#sec-guidelines) for
|
||||||
|
the actual guidelines.
|
||||||
|
|
||||||
|
This text is mainly directed at those who would like to make code
|
||||||
|
contributions to Home Manager. If you just want to report a bug then
|
||||||
|
first look among the already [open
|
||||||
|
issues](https://github.com/nix-community/home-manager/issues), if you
|
||||||
|
find one matching yours then feel free to comment on it to add any
|
||||||
|
additional information you may have. If no matching issue exists then go
|
||||||
|
to the [new
|
||||||
|
issue](https://github.com/nix-community/home-manager/issues/new) page
|
||||||
|
and write a description of your problem. Include as much information as
|
||||||
|
you can, ideally also include relevant excerpts from your Home Manager
|
||||||
|
configuration.
|
||||||
|
|
||||||
|
```{=include=} sections
|
||||||
|
contributing/getting-started.md
|
||||||
|
contributing/guidelines.md
|
||||||
|
contributing/news.md
|
||||||
|
contributing/tests.md
|
||||||
|
```
|
||||||
43
docs/manual/contributing/getting-started.md
Normal file
43
docs/manual/contributing/getting-started.md
Normal file
|
|
@ -0,0 +1,43 @@
|
||||||
|
# Getting started {#sec-contrib-getting-started}
|
||||||
|
|
||||||
|
If you have not previously forked Home Manager then you need to do that
|
||||||
|
first. Have a look at GitHub's [Fork a
|
||||||
|
repo](https://help.github.com/articles/fork-a-repo/) for instructions on
|
||||||
|
how to do this.
|
||||||
|
|
||||||
|
Once you have a fork of Home Manager you should create a branch starting
|
||||||
|
at the most recent `master` branch. Give your branch a reasonably
|
||||||
|
descriptive name. Commit your changes to this branch and when you are
|
||||||
|
happy with the result and it fulfills [Guidelines](#sec-guidelines) then
|
||||||
|
push the branch to GitHub and [create a pull
|
||||||
|
request](https://help.github.com/articles/creating-a-pull-request/).
|
||||||
|
|
||||||
|
Assuming your clone is at `$HOME/devel/home-manager` then you can make
|
||||||
|
the `home-manager` command use it by either
|
||||||
|
|
||||||
|
1. overriding the default path by using the `-I` command line option:
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ home-manager -I home-manager=$HOME/devel/home-manager
|
||||||
|
```
|
||||||
|
|
||||||
|
or, if using [flakes](#sec-flakes-standalone):
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ home-manager --override-input home-manager ~/devel/home-manager
|
||||||
|
```
|
||||||
|
|
||||||
|
or
|
||||||
|
|
||||||
|
2. changing the default path by ensuring your configuration includes
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
programs.home-manager.enable = true;
|
||||||
|
programs.home-manager.path = "$HOME/devel/home-manager";
|
||||||
|
```
|
||||||
|
|
||||||
|
and running `home-manager switch` to activate the change.
|
||||||
|
Afterwards, `home-manager build` and `home-manager switch` will use
|
||||||
|
your cloned repository.
|
||||||
|
|
||||||
|
The first option is good if you only temporarily want to use your clone.
|
||||||
221
docs/manual/contributing/guidelines.md
Normal file
221
docs/manual/contributing/guidelines.md
Normal file
|
|
@ -0,0 +1,221 @@
|
||||||
|
# Guidelines {#sec-guidelines}
|
||||||
|
|
||||||
|
If your contribution satisfy the following rules then there is a good
|
||||||
|
chance it will be merged without too much trouble. The rules are
|
||||||
|
enforced by the Home Manager maintainers and to a lesser extent the Home
|
||||||
|
Manager CI system.
|
||||||
|
|
||||||
|
If you are uncertain how these rules affect the change you would like to
|
||||||
|
make then feel free to start a discussion in the
|
||||||
|
[#home-manager](https://webchat.oftc.net/?channels=home-manager) IRC
|
||||||
|
channel, ideally before you start developing.
|
||||||
|
|
||||||
|
## Maintain backward compatibility {#sec-guidelines-back-compat}
|
||||||
|
|
||||||
|
Your contribution should not cause another user's existing configuration
|
||||||
|
to break unless there is a very good reason and the change should be
|
||||||
|
announced to the user through an
|
||||||
|
[assertion](https://nixos.org/manual/nixos/stable/index.html#sec-assertions)
|
||||||
|
or similar.
|
||||||
|
|
||||||
|
Remember that Home Manager is used in many different environments and
|
||||||
|
you should consider how your change may effect others. For example,
|
||||||
|
|
||||||
|
- Does your change work for people that do not use NixOS? Consider
|
||||||
|
other GNU/Linux distributions and macOS.
|
||||||
|
|
||||||
|
- Does your change work for people whose configuration is built on one
|
||||||
|
system and deployed on another system?
|
||||||
|
|
||||||
|
## Keep forward compatibility in mind {#sec-guidelines-forward-compat}
|
||||||
|
|
||||||
|
The master branch of Home Manager tracks the unstable channel of
|
||||||
|
Nixpkgs, which may update package versions at any time. It is therefore
|
||||||
|
important to consider how a package update may affect your code and try
|
||||||
|
to reduce the risk of breakage.
|
||||||
|
|
||||||
|
The most effective way to reduce this risk is to follow the advice in
|
||||||
|
[Add only valuable options](#sec-guidelines-valuable-options).
|
||||||
|
|
||||||
|
## Add only valuable options {#sec-guidelines-valuable-options}
|
||||||
|
|
||||||
|
When creating a new module it is tempting to include every option
|
||||||
|
supported by the software. This is *strongly* discouraged. Providing
|
||||||
|
many options increases maintenance burden and risk of breakage
|
||||||
|
considerably. This is why only the most [important software
|
||||||
|
options](https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md#valuable-options)
|
||||||
|
should be modeled explicitly. Less important options should be
|
||||||
|
expressible through an `extraConfig` escape hatch.
|
||||||
|
|
||||||
|
A good rule of thumb for the first implementation of a module is to only
|
||||||
|
add explicit options for those settings that absolutely must be set for
|
||||||
|
the software to function correctly. It follows that a module for
|
||||||
|
software that provides sensible default values for all settings would
|
||||||
|
require no explicit options at all.
|
||||||
|
|
||||||
|
If the software uses a structured configuration format like a JSON,
|
||||||
|
YAML, INI, TOML, or even a plain list of key/value pairs then consider
|
||||||
|
using a `settings` option as described in [Nix RFC
|
||||||
|
42](https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md).
|
||||||
|
|
||||||
|
## Add relevant tests {#sec-guidelines-add-tests}
|
||||||
|
|
||||||
|
If at all possible, make sure to add new tests and expand existing tests
|
||||||
|
so that your change will keep working in the future. See
|
||||||
|
[Tests](#sec-tests) for more information about the Home Manager test
|
||||||
|
suite.
|
||||||
|
|
||||||
|
All contributed code *must* pass the test suite.
|
||||||
|
|
||||||
|
## Add relevant documentation {#sec-guidelines-module-maintainer}
|
||||||
|
|
||||||
|
Many code changes require changing the documentation as well. Module
|
||||||
|
options should be documented with [Nixpkgs-flavoured
|
||||||
|
Markdown](https://nixos.org/manual/nixpkgs/unstable/#sec-contributing-markup).
|
||||||
|
Home Manager is itself documented using a combination of
|
||||||
|
[DocBook](https://tdg.docbook.org/) and
|
||||||
|
[AsciiDoc](https://asciidoc.org/). All text is hosted in Home Manager's
|
||||||
|
Git repository.
|
||||||
|
|
||||||
|
The HTML version of the manual containing both the module option
|
||||||
|
descriptions and the documentation of Home Manager can be generated and
|
||||||
|
opened by typing the following in a shell within a clone of the Home
|
||||||
|
Manager Git repository:
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix-build -A docs.html
|
||||||
|
$ xdg-open ./result/share/doc/home-manager/index.html
|
||||||
|
```
|
||||||
|
|
||||||
|
When you have made changes to a module, it is a good idea to check that
|
||||||
|
the man page version of the module options looks good:
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix-build -A docs.manPages
|
||||||
|
$ man ./result/share/man/man5/home-configuration.nix.5.gz
|
||||||
|
```
|
||||||
|
|
||||||
|
## Add yourself as a module maintainer {#_add_yourself_as_a_module_maintainer}
|
||||||
|
|
||||||
|
Every new module *must* include a named maintainer using the
|
||||||
|
`meta.maintainers` attribute. If you are a user of a module that
|
||||||
|
currently lacks a maintainer then please consider adopting it.
|
||||||
|
|
||||||
|
If you are present in the nixpkgs maintainer list then you can use that
|
||||||
|
entry. If you are not then you can add yourself to
|
||||||
|
`modules/lib/maintainers.nix` in the Home Manager project.
|
||||||
|
|
||||||
|
Maintainers are encouraged to join the IRC or Matrix channel and
|
||||||
|
participate when they have opportunity.
|
||||||
|
|
||||||
|
## Format your code {#sec-guidelines-code-style}
|
||||||
|
|
||||||
|
Make sure your code is formatted as described in [Code
|
||||||
|
Style](#sec-code-style). To maintain consistency throughout the project
|
||||||
|
you are encouraged to browse through existing code and adopt its style
|
||||||
|
also in new code.
|
||||||
|
|
||||||
|
## Format your commit messages {#sec-guidelines-commit-message-style}
|
||||||
|
|
||||||
|
Similar to [Format your code](#sec-guidelines-code-style) we encourage a
|
||||||
|
consistent commit message format as described in
|
||||||
|
[Commits](#sec-commit-style).
|
||||||
|
|
||||||
|
## Format your news entries {#sec-guidelines-news-style}
|
||||||
|
|
||||||
|
If your contribution includes a change that should be communicated to
|
||||||
|
users of Home Manager then you can add a news entry. The entry must be
|
||||||
|
formatted as described in [News](#sec-news).
|
||||||
|
|
||||||
|
When new modules are added a news entry should be included but you do
|
||||||
|
not need to create this entry manually. The merging maintainer will
|
||||||
|
create the entry for you. This is to reduce the risk of merge conflicts.
|
||||||
|
|
||||||
|
## Use conditional modules and news {#sec-guidelines-conditional-modules}
|
||||||
|
|
||||||
|
Home Manager includes a number of modules that are only usable on some
|
||||||
|
of the supported platforms. The most common example of platform specific
|
||||||
|
modules are those that define systemd user services, which only works on
|
||||||
|
Linux systems.
|
||||||
|
|
||||||
|
If you add a module that is platform specific then make sure to include
|
||||||
|
a condition in the `loadModule` function call. This will make the module
|
||||||
|
accessible only on systems where the condition evaluates to `true`.
|
||||||
|
|
||||||
|
Similarly, if you are adding a news entry then it should be shown only
|
||||||
|
to users that may find it relevant, see [News](#sec-news) for a
|
||||||
|
description of conditional news.
|
||||||
|
|
||||||
|
## Mind the license {#sec-guidelines-licensing}
|
||||||
|
|
||||||
|
The Home Manager project is covered by the MIT license and we can only
|
||||||
|
accept contributions that fall under this license, or are licensed in a
|
||||||
|
compatible way. When you contribute self written code and documentation
|
||||||
|
it is assumed that you are doing so under the MIT license.
|
||||||
|
|
||||||
|
A potential gotcha with respect to licensing are option descriptions.
|
||||||
|
Often it is convenient to copy from the upstream software documentation.
|
||||||
|
When this is done it is important to verify that the license of the
|
||||||
|
upstream documentation allows redistribution under the terms of the MIT
|
||||||
|
license.
|
||||||
|
|
||||||
|
## Commits {#sec-commit-style}
|
||||||
|
|
||||||
|
The commits in your pull request should be reasonably self-contained,
|
||||||
|
that is, each commit should make sense in isolation. In particular, you
|
||||||
|
will be asked to amend any commit that introduces syntax errors or
|
||||||
|
similar problems even if they are fixed in a later commit.
|
||||||
|
|
||||||
|
The commit messages should follow the [seven
|
||||||
|
rules](https://chris.beams.io/posts/git-commit/#seven-rules), except for
|
||||||
|
\"Capitalize the subject line\". We also ask you to include the affected
|
||||||
|
code component or module in the first line. That is, a commit message
|
||||||
|
should follow the template
|
||||||
|
|
||||||
|
{component}: {description}
|
||||||
|
|
||||||
|
{long description}
|
||||||
|
|
||||||
|
where `{component}` refers to the code component (or module) your change
|
||||||
|
affects, `{description}` is a very brief description of your change, and
|
||||||
|
`{long description}` is an optional clarifying description. As a rare
|
||||||
|
exception, if there is no clear component, or your change affects many
|
||||||
|
components, then the `{component}` part is optional. See
|
||||||
|
[example_title](#ex-commit-message) for a commit message that fulfills
|
||||||
|
these requirements.
|
||||||
|
|
||||||
|
## Example commit {#ex-commit-message}
|
||||||
|
|
||||||
|
The commit
|
||||||
|
[69f8e47e9e74c8d3d060ca22e18246b7f7d988ef](https://github.com/nix-community/home-manager/commit/69f8e47e9e74c8d3d060ca22e18246b7f7d988ef)
|
||||||
|
contains the commit message
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
starship: allow running in Emacs if vterm is used
|
||||||
|
|
||||||
|
The vterm buffer is backed by libvterm and can handle Starship prompts
|
||||||
|
without issues.
|
||||||
|
```
|
||||||
|
|
||||||
|
which ticks all the boxes necessary to be accepted in Home Manager.
|
||||||
|
|
||||||
|
Finally, when adding a new module, say `programs/foo.nix`, we use the
|
||||||
|
fixed commit format `foo: add module`. You can, of course, still include
|
||||||
|
a long description if you wish.
|
||||||
|
|
||||||
|
## Code Style {#sec-code-style}
|
||||||
|
|
||||||
|
The code in Home Manager is formatted by the
|
||||||
|
[nixfmt](https://github.com/serokell/nixfmt/) tool and the formatting is
|
||||||
|
checked in the pull request tests. Run the `format` tool inside the
|
||||||
|
project repository before submitting your pull request.
|
||||||
|
|
||||||
|
Keep lines at a reasonable width, ideally 80 characters or less. This
|
||||||
|
also applies to string literals.
|
||||||
|
|
||||||
|
We prefer `lowerCamelCase` for variable and attribute names with the
|
||||||
|
accepted exception of variables directly referencing packages in Nixpkgs
|
||||||
|
which use a hyphenated style. For example, the Home Manager option
|
||||||
|
`services.gpg-agent.enableSshSupport` references the `gpg-agent` package
|
||||||
|
in Nixpkgs.
|
||||||
57
docs/manual/contributing/news.md
Normal file
57
docs/manual/contributing/news.md
Normal file
|
|
@ -0,0 +1,57 @@
|
||||||
|
# News {#sec-news}
|
||||||
|
|
||||||
|
Home Manager includes a system for presenting news to the user. When
|
||||||
|
making a change you, therefore, have the option to also include an
|
||||||
|
associated news entry. In general, a news entry should only be added for
|
||||||
|
truly noteworthy news. For example, a bug fix or new option does
|
||||||
|
generally not need a news entry.
|
||||||
|
|
||||||
|
If you do have a change worthy of a news entry then please add one in
|
||||||
|
[`news.nix`](https://github.com/nix-community/home-manager/blob/master/modules/misc/news.nix)
|
||||||
|
but you should follow some basic guidelines:
|
||||||
|
|
||||||
|
- The entry timestamp should be in ISO-8601 format having \"+00:00\"
|
||||||
|
as time zone. For example, \"2017-09-13T17:10:14+00:00\". A suitable
|
||||||
|
timestamp can be produced by the command
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ date --iso-8601=second --universal
|
||||||
|
```
|
||||||
|
|
||||||
|
- The entry condition should be as specific as possible. For example,
|
||||||
|
if you are changing or deprecating a specific option then you could
|
||||||
|
restrict the news to those users who actually use this option.
|
||||||
|
|
||||||
|
- Wrap the news message so that it will fit in the typical terminal,
|
||||||
|
that is, at most 80 characters wide. Ideally a bit less.
|
||||||
|
|
||||||
|
- Unlike commit messages, news will be read without any connection to
|
||||||
|
the Home Manager source code. It is therefore important to make the
|
||||||
|
message understandable in isolation and to those who do not have
|
||||||
|
knowledge of the Home Manager internals. To this end it should be
|
||||||
|
written in more descriptive, prose like way.
|
||||||
|
|
||||||
|
- If you refer to an option then write its full attribute path. That
|
||||||
|
is, instead of writing
|
||||||
|
|
||||||
|
The option 'foo' has been deprecated, please use 'bar' instead.
|
||||||
|
|
||||||
|
it should read
|
||||||
|
|
||||||
|
The option 'services.myservice.foo' has been deprecated, please
|
||||||
|
use 'services.myservice.bar' instead.
|
||||||
|
|
||||||
|
- A new module, say `foo.nix`, should always include a news entry that
|
||||||
|
has a message along the lines of
|
||||||
|
|
||||||
|
A new module is available: 'services.foo'.
|
||||||
|
|
||||||
|
If the module is platform specific, e.g., a service module using
|
||||||
|
systemd, then a condition like
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
condition = hostPlatform.isLinux;
|
||||||
|
```
|
||||||
|
|
||||||
|
should be added. If you contribute a module then you don't need to
|
||||||
|
add this entry, the merger will create an entry for you.
|
||||||
38
docs/manual/contributing/tests.md
Normal file
38
docs/manual/contributing/tests.md
Normal file
|
|
@ -0,0 +1,38 @@
|
||||||
|
# Tests {#sec-tests}
|
||||||
|
|
||||||
|
Home Manager includes a basic test suite and it is highly recommended to
|
||||||
|
include at least one test when adding a module. Tests are typically in
|
||||||
|
the form of \"golden tests\" where, for example, a generated
|
||||||
|
configuration file is compared to a known correct file.
|
||||||
|
|
||||||
|
It is relatively easy to create tests by modeling the existing tests,
|
||||||
|
found in the `tests` project directory. For a full reference to the
|
||||||
|
functions available in test scripts, you can look at NMT's
|
||||||
|
[bash-lib](https://git.sr.ht/~rycee/nmt/tree/master/item/bash-lib).
|
||||||
|
|
||||||
|
The full Home Manager test suite can be run by executing
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix-shell --pure tests -A run.all
|
||||||
|
```
|
||||||
|
|
||||||
|
in the project root. List all test cases through
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix-shell --pure tests -A list
|
||||||
|
```
|
||||||
|
|
||||||
|
and run an individual test, for example `alacritty-empty-settings`,
|
||||||
|
through
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix-shell --pure tests -A run.alacritty-empty-settings
|
||||||
|
```
|
||||||
|
|
||||||
|
However, those invocations will impurely source the system's nixpkgs,
|
||||||
|
and may cause failures. To run against the nixpkgs from the flake.lock,
|
||||||
|
use instead e.g.
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix develop --ignore-environment .#all
|
||||||
|
```
|
||||||
10
docs/manual/faq.md
Normal file
10
docs/manual/faq.md
Normal file
|
|
@ -0,0 +1,10 @@
|
||||||
|
# Frequently Asked Questions (FAQ) {#ch-faq}
|
||||||
|
|
||||||
|
```{=include=} sections
|
||||||
|
faq/collision.md
|
||||||
|
faq/session-variables.md
|
||||||
|
faq/multiple-users-machines.md
|
||||||
|
faq/ca-desrt-dconf.md
|
||||||
|
faq/unstable.md
|
||||||
|
faq/override-package-module.md
|
||||||
|
```
|
||||||
19
docs/manual/faq/ca-desrt-dconf.md
Normal file
19
docs/manual/faq/ca-desrt-dconf.md
Normal file
|
|
@ -0,0 +1,19 @@
|
||||||
|
# Why do I get an error message about `ca.desrt.dconf` or `dconf.service`? {#_why_do_i_get_an_error_message_about_literal_ca_desrt_dconf_literal_or_literal_dconf_service_literal}
|
||||||
|
|
||||||
|
You are most likely trying to configure something that uses dconf but
|
||||||
|
the DBus session is not aware of the dconf service. The full error you
|
||||||
|
might get is
|
||||||
|
|
||||||
|
error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name ca.desrt.dconf was not provided by any .service files
|
||||||
|
|
||||||
|
or
|
||||||
|
|
||||||
|
error: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit dconf.service not found.
|
||||||
|
|
||||||
|
The solution on NixOS is to add
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
programs.dconf.enable = true;
|
||||||
|
```
|
||||||
|
|
||||||
|
to your system configuration.
|
||||||
47
docs/manual/faq/collision.md
Normal file
47
docs/manual/faq/collision.md
Normal file
|
|
@ -0,0 +1,47 @@
|
||||||
|
# Why is there a collision error when switching generation? {#_why_is_there_a_collision_error_when_switching_generation}
|
||||||
|
|
||||||
|
Home Manager currently installs packages into the user environment,
|
||||||
|
precisely as if the packages were installed through `nix-env --install`.
|
||||||
|
This means that you will get a collision error if your Home Manager
|
||||||
|
configuration attempts to install a package that you already have
|
||||||
|
installed manually, that is, packages that shows up when you run
|
||||||
|
`nix-env --query`.
|
||||||
|
|
||||||
|
For example, imagine you have the `hello` package installed in your
|
||||||
|
environment
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix-env --query
|
||||||
|
hello-2.10
|
||||||
|
```
|
||||||
|
|
||||||
|
and your Home Manager configuration contains
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
home.packages = [ pkgs.hello ];
|
||||||
|
```
|
||||||
|
|
||||||
|
Then attempting to switch to this configuration will result in an error
|
||||||
|
similar to
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ home-manager switch
|
||||||
|
these derivations will be built:
|
||||||
|
/nix/store/xg69wsnd1rp8xgs9qfsjal017nf0ldhm-home-manager-path.drv
|
||||||
|
[…]
|
||||||
|
Activating installPackages
|
||||||
|
replacing old ‘home-manager-path’
|
||||||
|
installing ‘home-manager-path’
|
||||||
|
building path(s) ‘/nix/store/b5c0asjz9f06l52l9812w6k39ifr49jj-user-environment’
|
||||||
|
Wide character in die at /nix/store/64jc9gd2rkbgdb4yjx3nrgc91bpjj5ky-buildenv.pl line 79.
|
||||||
|
collision between ‘/nix/store/fmwa4axzghz11cnln5absh31nbhs9lq1-home-manager-path/bin/hello’ and ‘/nix/store/c2wyl8b9p4afivpcz8jplc9kis8rj36d-hello-2.10/bin/hello’; use ‘nix-env --set-flag priority NUMBER PKGNAME’ to change the priority of one of the conflicting packages
|
||||||
|
builder for ‘/nix/store/b37x3s7pzxbasfqhaca5dqbf3pjjw0ip-user-environment.drv’ failed with exit code 2
|
||||||
|
error: build of ‘/nix/store/b37x3s7pzxbasfqhaca5dqbf3pjjw0ip-user-environment.drv’ failed
|
||||||
|
```
|
||||||
|
|
||||||
|
The solution is typically to uninstall the package from the environment
|
||||||
|
using `nix-env --uninstall` and reattempt the Home Manager generation
|
||||||
|
switch.
|
||||||
|
|
||||||
|
You could also opt to unistall *all* of the packages from your profile
|
||||||
|
with `nix-env --uninstall '*'`.
|
||||||
39
docs/manual/faq/multiple-users-machines.md
Normal file
39
docs/manual/faq/multiple-users-machines.md
Normal file
|
|
@ -0,0 +1,39 @@
|
||||||
|
# How to set up a configuration for multiple users/machines? {#_how_to_set_up_a_configuration_for_multiple_users_machines}
|
||||||
|
|
||||||
|
A typical way to prepare a repository of configurations for multiple
|
||||||
|
logins and machines is to prepare one \"top-level\" file for each unique
|
||||||
|
combination.
|
||||||
|
|
||||||
|
For example, if you have two machines, called \"kronos\" and \"rhea\" on
|
||||||
|
which you want to configure your user \"jane\" then you could create the
|
||||||
|
files
|
||||||
|
|
||||||
|
- `kronos-jane.nix`,
|
||||||
|
|
||||||
|
- `rhea-jane.nix`, and
|
||||||
|
|
||||||
|
- `common.nix`
|
||||||
|
|
||||||
|
in your repository. On the kronos and rhea machines you can then make
|
||||||
|
`~jane/.config/home-manager/home.nix` be a symbolic link to the
|
||||||
|
corresponding file in your configuration repository.
|
||||||
|
|
||||||
|
The `kronos-jane.nix` and `rhea-jane.nix` files follow the format
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
{ ... }:
|
||||||
|
|
||||||
|
{
|
||||||
|
imports = [ ./common.nix ];
|
||||||
|
|
||||||
|
# Various options that are specific for this machine/user.
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
while the `common.nix` file contains configuration shared across the two
|
||||||
|
logins. Of course, instead of just a single `common.nix` file you can
|
||||||
|
have multiple ones, even one per program or service.
|
||||||
|
|
||||||
|
You can get some inspiration from the [Post your home-manager home.nix
|
||||||
|
file!](https://www.reddit.com/r/NixOS/comments/9bb9h9/post_your_homemanager_homenix_file/)
|
||||||
|
Reddit thread.
|
||||||
44
docs/manual/faq/override-package-module.md
Normal file
44
docs/manual/faq/override-package-module.md
Normal file
|
|
@ -0,0 +1,44 @@
|
||||||
|
# How do I override the package used by a module? {#_how_do_i_override_the_package_used_by_a_module}
|
||||||
|
|
||||||
|
By default Home Manager will install the package provided by your chosen
|
||||||
|
`nixpkgs` channel but occasionally you might end up needing to change
|
||||||
|
this package. This can typically be done in two ways.
|
||||||
|
|
||||||
|
1. If the module provides a `package` option, such as
|
||||||
|
`programs.beets.package`, then this is the recommended way to
|
||||||
|
perform the override. For example,
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
programs.beets.package = pkgs.beets.override { enableCheck = true; };
|
||||||
|
```
|
||||||
|
|
||||||
|
2. If no `package` option is available then you can typically override
|
||||||
|
the relevant package using an
|
||||||
|
[overlay](https://nixos.org/nixpkgs/manual/#chap-overlays).
|
||||||
|
|
||||||
|
For example, if you want to use the `programs.skim` module but use
|
||||||
|
the `skim` package from Nixpkgs unstable, then a configuration like
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
{ pkgs, config, ... }:
|
||||||
|
|
||||||
|
let
|
||||||
|
|
||||||
|
pkgsUnstable = import <nixpkgs-unstable> {};
|
||||||
|
|
||||||
|
in
|
||||||
|
|
||||||
|
{
|
||||||
|
programs.skim.enable = true;
|
||||||
|
|
||||||
|
nixpkgs.overlays = [
|
||||||
|
(self: super: {
|
||||||
|
skim = pkgsUnstable.skim;
|
||||||
|
})
|
||||||
|
];
|
||||||
|
|
||||||
|
# …
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
should work OK.
|
||||||
24
docs/manual/faq/session-variables.md
Normal file
24
docs/manual/faq/session-variables.md
Normal file
|
|
@ -0,0 +1,24 @@
|
||||||
|
# Why are the session variables not set? {#_why_are_the_session_variables_not_set}
|
||||||
|
|
||||||
|
Home Manager is only able to set session variables automatically if it
|
||||||
|
manages your Bash, Z shell, or fish shell configuration. To enable such
|
||||||
|
management you use [programs.bash.enable](#opt-programs.bash.enable),
|
||||||
|
[programs.zsh.enable](#opt-programs.zsh.enable), or [programs.fish.enable](#opt-programs.fish.enable).
|
||||||
|
|
||||||
|
If you don't want to let Home Manager manage your shell then you will
|
||||||
|
have to manually source the
|
||||||
|
`~/.nix-profile/etc/profile.d/hm-session-vars.sh` file in an appropriate
|
||||||
|
way. In Bash and Z shell this can be done by adding
|
||||||
|
|
||||||
|
``` bash
|
||||||
|
. "$HOME/.nix-profile/etc/profile.d/hm-session-vars.sh"
|
||||||
|
```
|
||||||
|
|
||||||
|
to your `.profile` and `.zshrc` files, respectively. The
|
||||||
|
`hm-session-vars.sh` file should work in most Bourne-like shells. For
|
||||||
|
fish shell, it is possible to source it using [the foreign-env
|
||||||
|
plugin](https://github.com/oh-my-fish/plugin-foreign-env)
|
||||||
|
|
||||||
|
``` bash
|
||||||
|
fenv source "$HOME/.nix-profile/etc/profile.d/hm-session-vars.sh" > /dev/null
|
||||||
|
```
|
||||||
36
docs/manual/faq/unstable.md
Normal file
36
docs/manual/faq/unstable.md
Normal file
|
|
@ -0,0 +1,36 @@
|
||||||
|
# How do I install packages from Nixpkgs unstable? {#_how_do_i_install_packages_from_nixpkgs_unstable}
|
||||||
|
|
||||||
|
If you are using a stable version of Nixpkgs but would like to install
|
||||||
|
some particular packages from Nixpkgs unstable -- or some other channel
|
||||||
|
-- then you can import the unstable Nixpkgs and refer to its packages
|
||||||
|
within your configuration. Something like
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
{ pkgs, config, ... }:
|
||||||
|
|
||||||
|
let
|
||||||
|
|
||||||
|
pkgsUnstable = import <nixpkgs-unstable> {};
|
||||||
|
|
||||||
|
in
|
||||||
|
|
||||||
|
{
|
||||||
|
home.packages = [
|
||||||
|
pkgsUnstable.foo
|
||||||
|
];
|
||||||
|
|
||||||
|
# …
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
should work provided you have a Nix channel called `nixpkgs-unstable`.
|
||||||
|
|
||||||
|
You can add the `nixpkgs-unstable` channel by running
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix-channel --add https://nixos.org/channels/nixpkgs-unstable nixpkgs-unstable
|
||||||
|
$ nix-channel --update
|
||||||
|
```
|
||||||
|
|
||||||
|
Note, the package will not be affected by any package overrides,
|
||||||
|
overlays, etc.
|
||||||
35
docs/manual/installation.md
Normal file
35
docs/manual/installation.md
Normal file
|
|
@ -0,0 +1,35 @@
|
||||||
|
# Installing Home Manager {#ch-installation}
|
||||||
|
|
||||||
|
Home Manager can be used in three primary ways:
|
||||||
|
|
||||||
|
1. Using the standalone `home-manager` tool. For platforms other than
|
||||||
|
NixOS and Darwin, this is the only available choice. It is also
|
||||||
|
recommended for people on NixOS or Darwin that want to manage their
|
||||||
|
home directory independently of the system as a whole. See
|
||||||
|
[Standalone installation](#sec-install-standalone) for instructions
|
||||||
|
on how to perform this installation.
|
||||||
|
|
||||||
|
2. As a module within a NixOS system configuration. This allows the
|
||||||
|
user profiles to be built together with the system when running
|
||||||
|
`nixos-rebuild`. See [NixOS module](#sec-install-nixos-module) for a
|
||||||
|
description of this setup.
|
||||||
|
|
||||||
|
3. As a module within a
|
||||||
|
[nix-darwin](https://github.com/LnL7/nix-darwin/) system
|
||||||
|
configuration. This allows the user profiles to be built together
|
||||||
|
with the system when running `darwin-rebuild`. See [nix-darwin
|
||||||
|
module](#sec-install-nix-darwin-module) for a description of this
|
||||||
|
setup.
|
||||||
|
|
||||||
|
:::{.note}
|
||||||
|
In this chapter we describe how to install Home Manager in the standard
|
||||||
|
way using channels. If you prefer to use [Nix
|
||||||
|
Flakes](https://nixos.wiki/wiki/Flakes) then please see the instructions
|
||||||
|
in [nix flakes](#ch-nix-flakes).
|
||||||
|
:::
|
||||||
|
|
||||||
|
```{=include=} sections
|
||||||
|
installation/standalone.md
|
||||||
|
installation/nixos.md
|
||||||
|
installation/nix-darwin.md
|
||||||
|
```
|
||||||
115
docs/manual/installation/nix-darwin.md
Normal file
115
docs/manual/installation/nix-darwin.md
Normal file
|
|
@ -0,0 +1,115 @@
|
||||||
|
# nix-darwin module {#sec-install-nix-darwin-module}
|
||||||
|
|
||||||
|
Home Manager provides a module that allows you to prepare user
|
||||||
|
environments directly from the
|
||||||
|
[nix-darwin](https://github.com/LnL7/nix-darwin/) configuration file,
|
||||||
|
which often is more convenient than using the `home-manager` tool.
|
||||||
|
|
||||||
|
To make the NixOS module available for use you must `import` it into
|
||||||
|
your system configuration. This is most conveniently done by adding a
|
||||||
|
Home Manager channel. For example, if you are following Nixpkgs master
|
||||||
|
or an unstable channel, you can run
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix-channel --add https://github.com/nix-community/home-manager/archive/master.tar.gz home-manager
|
||||||
|
$ nix-channel --update
|
||||||
|
```
|
||||||
|
|
||||||
|
and if you follow a Nixpkgs version 23.11 channel, you can run
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix-channel --add https://github.com/nix-community/home-manager/archive/release-23.11.tar.gz home-manager
|
||||||
|
$ nix-channel --update
|
||||||
|
```
|
||||||
|
|
||||||
|
It is then possible to add
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
imports = [ <home-manager/nix-darwin> ];
|
||||||
|
```
|
||||||
|
|
||||||
|
to your nix-darwin `configuration.nix` file, which will introduce a new
|
||||||
|
NixOS option called `home-manager` whose type is an attribute set that
|
||||||
|
maps user names to Home Manager configurations.
|
||||||
|
|
||||||
|
For example, a nix-darwin configuration may include the lines
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
users.users.eve = {
|
||||||
|
name = "eve";
|
||||||
|
home = "/Users/eve";
|
||||||
|
}
|
||||||
|
home-manager.users.eve = { pkgs, ... }: {
|
||||||
|
home.packages = [ pkgs.atool pkgs.httpie ];
|
||||||
|
programs.bash.enable = true;
|
||||||
|
|
||||||
|
# The state version is required and should stay at the version you
|
||||||
|
# originally installed.
|
||||||
|
home.stateVersion = "23.11";
|
||||||
|
};
|
||||||
|
```
|
||||||
|
|
||||||
|
and after a `darwin-rebuild switch` the user eve's environment should
|
||||||
|
include a basic Bash configuration and the packages atool and httpie.
|
||||||
|
|
||||||
|
If you do not plan on having Home Manager manage your shell
|
||||||
|
configuration then you must add either
|
||||||
|
|
||||||
|
``` bash
|
||||||
|
. "$HOME/.nix-profile/etc/profile.d/hm-session-vars.sh"
|
||||||
|
```
|
||||||
|
|
||||||
|
or
|
||||||
|
|
||||||
|
``` bash
|
||||||
|
. "/etc/profiles/per-user/$USER/etc/profile.d/hm-session-vars.sh"
|
||||||
|
```
|
||||||
|
|
||||||
|
to your shell configuration, depending on whether
|
||||||
|
[home-manager.useUserPackages](#nix-darwin-opt-home-manager.useUserPackages) is enabled. This
|
||||||
|
file can be sourced directly by POSIX.2-like shells such as
|
||||||
|
[Bash](https://www.gnu.org/software/bash/) or [Z
|
||||||
|
shell](http://zsh.sourceforge.net/). [Fish](https://fishshell.com) users
|
||||||
|
can use utilities such as
|
||||||
|
[foreign-env](https://github.com/oh-my-fish/plugin-foreign-env) or
|
||||||
|
[babelfish](https://github.com/bouk/babelfish).
|
||||||
|
|
||||||
|
:::{.note}
|
||||||
|
By default user packages will not be ignored in favor of
|
||||||
|
`environment.systemPackages`, but they will be installed to
|
||||||
|
`/etc/profiles/per-user/$USERNAME` if
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
home-manager.useUserPackages = true;
|
||||||
|
```
|
||||||
|
|
||||||
|
is added to the nix-darwin configuration. This option may become the
|
||||||
|
default value in the future.
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::{.note}
|
||||||
|
By default, Home Manager uses a private `pkgs` instance that is
|
||||||
|
configured via the `home-manager.users.<name>.nixpkgs` options. To
|
||||||
|
instead use the global `pkgs` that is configured via the system level
|
||||||
|
`nixpkgs` options, set
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
home-manager.useGlobalPkgs = true;
|
||||||
|
```
|
||||||
|
|
||||||
|
This saves an extra Nixpkgs evaluation, adds consistency, and removes
|
||||||
|
the dependency on `NIX_PATH`, which is otherwise used for importing
|
||||||
|
Nixpkgs.
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::{.note}
|
||||||
|
Home Manager will pass `osConfig` as a module argument to any modules
|
||||||
|
you create. This contains the system's nix-darwin configuration.
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
{ lib, pkgs, osConfig, ... }:
|
||||||
|
```
|
||||||
|
:::
|
||||||
|
|
||||||
|
Once installed you can see [Using Home Manager](#ch-usage) for a more detailed
|
||||||
|
description of Home Manager and how to use it.
|
||||||
125
docs/manual/installation/nixos.md
Normal file
125
docs/manual/installation/nixos.md
Normal file
|
|
@ -0,0 +1,125 @@
|
||||||
|
# NixOS module {#sec-install-nixos-module}
|
||||||
|
|
||||||
|
Home Manager provides a NixOS module that allows you to prepare user
|
||||||
|
environments directly from the system configuration file, which often is
|
||||||
|
more convenient than using the `home-manager` tool. It also opens up
|
||||||
|
additional possibilities, for example, to automatically configure user
|
||||||
|
environments in NixOS declarative containers or on systems deployed
|
||||||
|
through NixOps.
|
||||||
|
|
||||||
|
To make the NixOS module available for use you must `import` it into
|
||||||
|
your system configuration. This is most conveniently done by adding a
|
||||||
|
Home Manager channel to the root user. For example, if you are following
|
||||||
|
Nixpkgs master or an unstable channel, you can run
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ sudo nix-channel --add https://github.com/nix-community/home-manager/archive/master.tar.gz home-manager
|
||||||
|
$ sudo nix-channel --update
|
||||||
|
```
|
||||||
|
|
||||||
|
and if you follow a Nixpkgs version 23.11 channel, you can run
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ sudo nix-channel --add https://github.com/nix-community/home-manager/archive/release-23.11.tar.gz home-manager
|
||||||
|
$ sudo nix-channel --update
|
||||||
|
```
|
||||||
|
|
||||||
|
It is then possible to add
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
imports = [ <home-manager/nixos> ];
|
||||||
|
```
|
||||||
|
|
||||||
|
to your system `configuration.nix` file, which will introduce a new
|
||||||
|
NixOS option called `home-manager.users` whose type is an attribute set
|
||||||
|
that maps user names to Home Manager configurations.
|
||||||
|
|
||||||
|
For example, a NixOS configuration may include the lines
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
users.users.eve.isNormalUser = true;
|
||||||
|
home-manager.users.eve = { pkgs, ... }: {
|
||||||
|
home.packages = [ pkgs.atool pkgs.httpie ];
|
||||||
|
programs.bash.enable = true;
|
||||||
|
|
||||||
|
# The state version is required and should stay at the version you
|
||||||
|
# originally installed.
|
||||||
|
home.stateVersion = "23.11";
|
||||||
|
};
|
||||||
|
```
|
||||||
|
|
||||||
|
and after a `sudo nixos-rebuild switch` the user eve's environment
|
||||||
|
should include a basic Bash configuration and the packages atool and
|
||||||
|
httpie.
|
||||||
|
|
||||||
|
:::{.note}
|
||||||
|
If `nixos-rebuild switch` does not result in the environment you expect,
|
||||||
|
you can take a look at the output of the Home Manager activation script
|
||||||
|
output using
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ systemctl status "home-manager-$USER.service"
|
||||||
|
```
|
||||||
|
:::
|
||||||
|
|
||||||
|
If you do not plan on having Home Manager manage your shell
|
||||||
|
configuration then you must add either
|
||||||
|
|
||||||
|
``` bash
|
||||||
|
. "$HOME/.nix-profile/etc/profile.d/hm-session-vars.sh"
|
||||||
|
```
|
||||||
|
|
||||||
|
or
|
||||||
|
|
||||||
|
``` bash
|
||||||
|
. "/etc/profiles/per-user/$USER/etc/profile.d/hm-session-vars.sh"
|
||||||
|
```
|
||||||
|
|
||||||
|
to your shell configuration, depending on whether
|
||||||
|
[home-manager.useUserPackages](#nixos-opt-home-manager.useUserPackages) is enabled. This file can
|
||||||
|
be sourced directly by POSIX.2-like shells such as
|
||||||
|
[Bash](https://www.gnu.org/software/bash/) or [Z
|
||||||
|
shell](http://zsh.sourceforge.net/). [Fish](https://fishshell.com) users
|
||||||
|
can use utilities such as
|
||||||
|
[foreign-env](https://github.com/oh-my-fish/plugin-foreign-env) or
|
||||||
|
[babelfish](https://github.com/bouk/babelfish).
|
||||||
|
|
||||||
|
:::{.note}
|
||||||
|
By default packages will be installed to `$HOME/.nix-profile` but they
|
||||||
|
can be installed to `/etc/profiles` if
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
home-manager.useUserPackages = true;
|
||||||
|
```
|
||||||
|
|
||||||
|
is added to the system configuration. This is necessary if, for example,
|
||||||
|
you wish to use `nixos-rebuild build-vm`. This option may become the
|
||||||
|
default value in the future.
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::{.note}
|
||||||
|
By default, Home Manager uses a private `pkgs` instance that is
|
||||||
|
configured via the `home-manager.users.<name>.nixpkgs` options. To
|
||||||
|
instead use the global `pkgs` that is configured via the system level
|
||||||
|
`nixpkgs` options, set
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
home-manager.useGlobalPkgs = true;
|
||||||
|
```
|
||||||
|
|
||||||
|
This saves an extra Nixpkgs evaluation, adds consistency, and removes
|
||||||
|
the dependency on `NIX_PATH`, which is otherwise used for importing
|
||||||
|
Nixpkgs.
|
||||||
|
:::
|
||||||
|
|
||||||
|
:::{.note}
|
||||||
|
Home Manager will pass `osConfig` as a module argument to any modules
|
||||||
|
you create. This contains the system's NixOS configuration.
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
{ lib, pkgs, osConfig, ... }:
|
||||||
|
```
|
||||||
|
:::
|
||||||
|
|
||||||
|
Once installed you can see [Using Home Manager](#ch-usage) for a more detailed
|
||||||
|
description of Home Manager and how to use it.
|
||||||
75
docs/manual/installation/standalone.md
Normal file
75
docs/manual/installation/standalone.md
Normal file
|
|
@ -0,0 +1,75 @@
|
||||||
|
# Standalone installation {#sec-install-standalone}
|
||||||
|
|
||||||
|
1. Make sure you have a working Nix installation. Specifically, make
|
||||||
|
sure that your user is able to build and install Nix packages. For
|
||||||
|
example, you should be able to successfully run a command like
|
||||||
|
`nix-instantiate '<nixpkgs>' -A hello` without having to switch to
|
||||||
|
the root user. For a multi-user install of Nix this means that your
|
||||||
|
user must be covered by the
|
||||||
|
[`allowed-users`](https://nixos.org/nix/manual/#conf-allowed-users)
|
||||||
|
Nix option. On NixOS you can control this option using the
|
||||||
|
[`nix.settings.allowed-users`](https://nixos.org/manual/nixos/stable/options.html#opt-nix.settings.allowed-users)
|
||||||
|
system option.
|
||||||
|
|
||||||
|
2. Add the appropriate Home Manager channel. If you are following
|
||||||
|
Nixpkgs master or an unstable channel you can run
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix-channel --add https://github.com/nix-community/home-manager/archive/master.tar.gz home-manager
|
||||||
|
$ nix-channel --update
|
||||||
|
```
|
||||||
|
|
||||||
|
and if you follow a Nixpkgs version 23.11 channel you can run
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix-channel --add https://github.com/nix-community/home-manager/archive/release-23.11.tar.gz home-manager
|
||||||
|
$ nix-channel --update
|
||||||
|
```
|
||||||
|
|
||||||
|
3. Run the Home Manager installation command and create the first Home
|
||||||
|
Manager generation:
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix-shell '<home-manager>' -A install
|
||||||
|
```
|
||||||
|
|
||||||
|
Once finished, Home Manager should be active and available in your
|
||||||
|
user environment.
|
||||||
|
|
||||||
|
4. If you do not plan on having Home Manager manage your shell
|
||||||
|
configuration then you must source the
|
||||||
|
|
||||||
|
``` bash
|
||||||
|
$HOME/.nix-profile/etc/profile.d/hm-session-vars.sh
|
||||||
|
```
|
||||||
|
|
||||||
|
file in your shell configuration. Alternatively source
|
||||||
|
|
||||||
|
``` bash
|
||||||
|
/etc/profiles/per-user/$USER/etc/profile.d/hm-session-vars.sh
|
||||||
|
```
|
||||||
|
|
||||||
|
when managing home configuration together with system configuration.
|
||||||
|
|
||||||
|
This file can be sourced directly by POSIX.2-like shells such as
|
||||||
|
[Bash](https://www.gnu.org/software/bash/) or [Z
|
||||||
|
shell](http://zsh.sourceforge.net/). [Fish](https://fishshell.com)
|
||||||
|
users can use utilities such as
|
||||||
|
[foreign-env](https://github.com/oh-my-fish/plugin-foreign-env) or
|
||||||
|
[babelfish](https://github.com/bouk/babelfish).
|
||||||
|
|
||||||
|
For example, if you use Bash then add
|
||||||
|
|
||||||
|
``` bash
|
||||||
|
. "$HOME/.nix-profile/etc/profile.d/hm-session-vars.sh"
|
||||||
|
```
|
||||||
|
|
||||||
|
to your `~/.profile` file.
|
||||||
|
|
||||||
|
If instead of using channels you want to run Home Manager from a Git
|
||||||
|
checkout of the repository then you can use the
|
||||||
|
[home-manager.path](#opt-programs.home-manager.path) option to specify the absolute
|
||||||
|
path to the repository.
|
||||||
|
|
||||||
|
Once installed you can see [Using Home Manager](#ch-usage) for a more detailed
|
||||||
|
description of Home Manager and how to use it.
|
||||||
32
docs/manual/manpage-urls.json
Normal file
32
docs/manual/manpage-urls.json
Normal file
|
|
@ -0,0 +1,32 @@
|
||||||
|
{
|
||||||
|
"gnunet.conf(5)": "https://docs.gnunet.org/users/configuration.html",
|
||||||
|
"mpd(1)": "https://mpd.readthedocs.io/en/latest/mpd.1.html",
|
||||||
|
"mpd.conf(5)": "https://mpd.readthedocs.io/en/latest/mpd.conf.5.html",
|
||||||
|
"nix.conf(5)": "https://nixos.org/manual/nix/stable/command-ref/conf-file.html",
|
||||||
|
|
||||||
|
"journald.conf(5)": "https://www.freedesktop.org/software/systemd/man/journald.conf.html",
|
||||||
|
"logind.conf(5)": "https://www.freedesktop.org/software/systemd/man/logind.conf.html",
|
||||||
|
"networkd.conf(5)": "https://www.freedesktop.org/software/systemd/man/networkd.conf.html",
|
||||||
|
"systemd.automount(5)": "https://www.freedesktop.org/software/systemd/man/systemd.automount.html",
|
||||||
|
"systemd.exec(5)": "https://www.freedesktop.org/software/systemd/man/systemd.exec.html",
|
||||||
|
"systemd.link(5)": "https://www.freedesktop.org/software/systemd/man/systemd.link.html",
|
||||||
|
"systemd.mount(5)": "https://www.freedesktop.org/software/systemd/man/systemd.mount.html",
|
||||||
|
"systemd.netdev(5)": "https://www.freedesktop.org/software/systemd/man/systemd.netdev.html",
|
||||||
|
"systemd.network(5)": "https://www.freedesktop.org/software/systemd/man/systemd.network.html",
|
||||||
|
"systemd.nspawn(5)": "https://www.freedesktop.org/software/systemd/man/systemd.nspawn.html",
|
||||||
|
"systemd.path(5)": "https://www.freedesktop.org/software/systemd/man/systemd.path.html",
|
||||||
|
"systemd.resource-control(5)": "https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html",
|
||||||
|
"systemd.scope(5)": "https://www.freedesktop.org/software/systemd/man/systemd.scope.html",
|
||||||
|
"systemd.service(5)": "https://www.freedesktop.org/software/systemd/man/systemd.service.html",
|
||||||
|
"systemd.slice(5)": "https://www.freedesktop.org/software/systemd/man/systemd.slice.html",
|
||||||
|
"systemd.socket(5)": "https://www.freedesktop.org/software/systemd/man/systemd.socket.html",
|
||||||
|
"systemd.timer(5)": "https://www.freedesktop.org/software/systemd/man/systemd.timer.html",
|
||||||
|
"systemd.unit(5)": "https://www.freedesktop.org/software/systemd/man/systemd.unit.html",
|
||||||
|
"systemd-system.conf(5)": "https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html",
|
||||||
|
"systemd-user.conf(5)": "https://www.freedesktop.org/software/systemd/man/systemd-user.conf.html",
|
||||||
|
"timesyncd.conf(5)": "https://www.freedesktop.org/software/systemd/man/timesyncd.conf.html",
|
||||||
|
"tmpfiles.d(5)": "https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html",
|
||||||
|
"systemd.time(7)": "https://www.freedesktop.org/software/systemd/man/systemd.time.html",
|
||||||
|
"systemd-fstab-generator(8)": "https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html",
|
||||||
|
"systemd-networkd-wait-online.service(8)": "https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html"
|
||||||
|
}
|
||||||
30
docs/manual/manual.md
Normal file
30
docs/manual/manual.md
Normal file
|
|
@ -0,0 +1,30 @@
|
||||||
|
# Home Manager Manual {#home-manager-manual}
|
||||||
|
|
||||||
|
## Version 23.11
|
||||||
|
|
||||||
|
|
||||||
|
```{=include=} preface
|
||||||
|
preface.md
|
||||||
|
```
|
||||||
|
|
||||||
|
```{=include=} parts
|
||||||
|
installation.md
|
||||||
|
usage.md
|
||||||
|
nix-flakes.md
|
||||||
|
writing-modules.md
|
||||||
|
contributing.md
|
||||||
|
3rd-party.md
|
||||||
|
faq.md
|
||||||
|
```
|
||||||
|
|
||||||
|
```{=include=} appendix html:into-file=//options.html
|
||||||
|
options.md
|
||||||
|
```
|
||||||
|
|
||||||
|
```{=include=} appendix html:into-file=//nixos-options.html
|
||||||
|
nixos-options.md
|
||||||
|
```
|
||||||
|
|
||||||
|
```{=include=} appendix html:into-file=//nix-darwin-options.html
|
||||||
|
nix-darwin-options.md
|
||||||
|
```
|
||||||
7
docs/manual/nix-darwin-options.md
Normal file
7
docs/manual/nix-darwin-options.md
Normal file
|
|
@ -0,0 +1,7 @@
|
||||||
|
# nix-darwin Configuration Options {#ch-nix-darwin-options}
|
||||||
|
|
||||||
|
```{=include=} options
|
||||||
|
id-prefix: nix-darwin-opt-
|
||||||
|
list-id: nix-darwin-options
|
||||||
|
source: @OPTIONS_JSON@
|
||||||
|
```
|
||||||
35
docs/manual/nix-flakes.md
Normal file
35
docs/manual/nix-flakes.md
Normal file
|
|
@ -0,0 +1,35 @@
|
||||||
|
# Nix Flakes {#ch-nix-flakes}
|
||||||
|
|
||||||
|
Home Manager is compatible with [Nix
|
||||||
|
Flakes](https://nixos.wiki/wiki/Flakes). But please be aware that the
|
||||||
|
support it is still experimental and may change in backwards
|
||||||
|
incompatible ways.
|
||||||
|
|
||||||
|
Just like in the standard installation you can use the Home Manager
|
||||||
|
flake in three ways:
|
||||||
|
|
||||||
|
1. Using the standalone `home-manager` tool. For platforms other than
|
||||||
|
NixOS and Darwin, this is the only available choice. It is also
|
||||||
|
recommended for people on NixOS or Darwin that want to manage their
|
||||||
|
home directory independently of the system as a whole. See
|
||||||
|
[Standalone setup](#sec-flakes-standalone) for instructions on how
|
||||||
|
to perform this installation.
|
||||||
|
|
||||||
|
2. As a module within a NixOS system configuration. This allows the
|
||||||
|
user profiles to be built together with the system when running
|
||||||
|
`nixos-rebuild`. See [NixOS module](#sec-flakes-nixos-module) for a
|
||||||
|
description of this setup.
|
||||||
|
|
||||||
|
3. This allows the user profiles to be built together with the system
|
||||||
|
when running `darwin-rebuild`. See [nix-darwin
|
||||||
|
module](#sec-flakes-nix-darwin-module) for a description of this
|
||||||
|
setup.
|
||||||
|
|
||||||
|
```{=include=} sections
|
||||||
|
nix-flakes/prerequisites.md
|
||||||
|
nix-flakes/standalone.md
|
||||||
|
nix-flakes/nixos.md
|
||||||
|
nix-flakes/nix-darwin.md
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
47
docs/manual/nix-flakes/nix-darwin.md
Normal file
47
docs/manual/nix-flakes/nix-darwin.md
Normal file
|
|
@ -0,0 +1,47 @@
|
||||||
|
# nix-darwin module {#sec-flakes-nix-darwin-module}
|
||||||
|
|
||||||
|
The flake-based setup of the Home Manager nix-darwin module is similar
|
||||||
|
to that of NixOS. The `flake.nix` would be:
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
{
|
||||||
|
description = "Darwin configuration";
|
||||||
|
|
||||||
|
inputs = {
|
||||||
|
nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
|
||||||
|
darwin.url = "github:lnl7/nix-darwin";
|
||||||
|
darwin.inputs.nixpkgs.follows = "nixpkgs";
|
||||||
|
home-manager.url = "github:nix-community/home-manager";
|
||||||
|
home-manager.inputs.nixpkgs.follows = "nixpkgs";
|
||||||
|
};
|
||||||
|
|
||||||
|
outputs = inputs@{ nixpkgs, home-manager, darwin, ... }: {
|
||||||
|
darwinConfigurations = {
|
||||||
|
hostname = darwin.lib.darwinSystem {
|
||||||
|
system = "x86_64-darwin";
|
||||||
|
modules = [
|
||||||
|
./configuration.nix
|
||||||
|
home-manager.darwinModules.home-manager
|
||||||
|
{
|
||||||
|
home-manager.useGlobalPkgs = true;
|
||||||
|
home-manager.useUserPackages = true;
|
||||||
|
home-manager.users.jdoe = import ./home.nix;
|
||||||
|
|
||||||
|
# Optionally, use home-manager.extraSpecialArgs to pass
|
||||||
|
# arguments to home.nix
|
||||||
|
}
|
||||||
|
];
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
and it is also rebuilt with the nix-darwin generations. The rebuild
|
||||||
|
command here may be `darwin-rebuild switch --flake <flake-uri>`.
|
||||||
|
|
||||||
|
You can use the above `flake.nix` as a template in `~/.config/darwin` by
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix flake new ~/.config/darwin -t github:nix-community/home-manager#nix-darwin
|
||||||
|
```
|
||||||
47
docs/manual/nix-flakes/nixos.md
Normal file
47
docs/manual/nix-flakes/nixos.md
Normal file
|
|
@ -0,0 +1,47 @@
|
||||||
|
# NixOS module {#sec-flakes-nixos-module}
|
||||||
|
|
||||||
|
To use Home Manager as a NixOS module, a bare-minimum `flake.nix` would
|
||||||
|
be as follows:
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
{
|
||||||
|
description = "NixOS configuration";
|
||||||
|
|
||||||
|
inputs = {
|
||||||
|
nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
|
||||||
|
home-manager.url = "github:nix-community/home-manager";
|
||||||
|
home-manager.inputs.nixpkgs.follows = "nixpkgs";
|
||||||
|
};
|
||||||
|
|
||||||
|
outputs = inputs@{ nixpkgs, home-manager, ... }: {
|
||||||
|
nixosConfigurations = {
|
||||||
|
hostname = nixpkgs.lib.nixosSystem {
|
||||||
|
system = "x86_64-linux";
|
||||||
|
modules = [
|
||||||
|
./configuration.nix
|
||||||
|
home-manager.nixosModules.home-manager
|
||||||
|
{
|
||||||
|
home-manager.useGlobalPkgs = true;
|
||||||
|
home-manager.useUserPackages = true;
|
||||||
|
home-manager.users.jdoe = import ./home.nix;
|
||||||
|
|
||||||
|
# Optionally, use home-manager.extraSpecialArgs to pass
|
||||||
|
# arguments to home.nix
|
||||||
|
}
|
||||||
|
];
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
The Home Manager configuration is then part of the NixOS configuration
|
||||||
|
and is automatically rebuilt with the system when using the appropriate
|
||||||
|
command for the system, such as
|
||||||
|
`nixos-rebuild switch --flake <flake-uri>`.
|
||||||
|
|
||||||
|
You can use the above `flake.nix` as a template in `/etc/nixos` by
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix flake new /etc/nixos -t github:nix-community/home-manager#nixos
|
||||||
|
```
|
||||||
42
docs/manual/nix-flakes/prerequisites.md
Normal file
42
docs/manual/nix-flakes/prerequisites.md
Normal file
|
|
@ -0,0 +1,42 @@
|
||||||
|
# Prerequisites {#sec-flakes-prerequisites}
|
||||||
|
|
||||||
|
- Install Nix 2.4 or later, or have it in `nix-shell`.
|
||||||
|
|
||||||
|
- Enable experimental features `nix-command` and `flakes`.
|
||||||
|
|
||||||
|
- When using NixOS, add the following to your `configuration.nix`
|
||||||
|
and rebuild your system.
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
nix = {
|
||||||
|
package = pkgs.nixFlakes;
|
||||||
|
extraOptions = ''
|
||||||
|
experimental-features = nix-command flakes
|
||||||
|
'';
|
||||||
|
};
|
||||||
|
```
|
||||||
|
|
||||||
|
- If you are not using NixOS, add the following to `nix.conf`
|
||||||
|
(located at `~/.config/nix/` or `/etc/nix/nix.conf`).
|
||||||
|
|
||||||
|
``` bash
|
||||||
|
experimental-features = nix-command flakes
|
||||||
|
```
|
||||||
|
|
||||||
|
You may need to restart the Nix daemon with, for example,
|
||||||
|
`sudo systemctl restart nix-daemon.service`.
|
||||||
|
|
||||||
|
- Alternatively, you can enable flakes on a per-command basis with
|
||||||
|
the following additional flags to `nix` and `home-manager`:
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix --extra-experimental-features "nix-command flakes" <sub-commands>
|
||||||
|
$ home-manager --extra-experimental-features "nix-command flakes" <sub-commands>
|
||||||
|
```
|
||||||
|
|
||||||
|
- Prepare your Home Manager configuration (`home.nix`).
|
||||||
|
|
||||||
|
Unlike the channel-based setup, `home.nix` will be evaluated when
|
||||||
|
the flake is built, so it must be present before bootstrap of Home
|
||||||
|
Manager from the flake. See [Configuration Example](#sec-usage-configuration) for
|
||||||
|
introduction about writing a Home Manager configuration.
|
||||||
62
docs/manual/nix-flakes/standalone.md
Normal file
62
docs/manual/nix-flakes/standalone.md
Normal file
|
|
@ -0,0 +1,62 @@
|
||||||
|
# Standalone setup {#sec-flakes-standalone}
|
||||||
|
|
||||||
|
To prepare an initial Home Manager configuration for your logged in
|
||||||
|
user, you can run the Home Manager `init` command directly from its
|
||||||
|
flake.
|
||||||
|
|
||||||
|
For example, if you are using the unstable version of Nixpkgs or NixOS,
|
||||||
|
then to generate and activate a basic configuration run the command
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix run home-manager/master -- init --switch
|
||||||
|
```
|
||||||
|
|
||||||
|
For Nixpkgs or NixOS version 23.11 run
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix run home-manager/release-23.11 -- init --switch
|
||||||
|
```
|
||||||
|
|
||||||
|
This will generate a `flake.nix` and a `home.nix` file in
|
||||||
|
`~/.config/home-manager`, creating the directory if it does not exist.
|
||||||
|
|
||||||
|
If you omit the `--switch` option then the activation will not happen.
|
||||||
|
This is useful if you want to inspect and edit the configuration before
|
||||||
|
activating it.
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix run home-manager/$branch -- init
|
||||||
|
$ # Edit files in ~/.config/home-manager
|
||||||
|
$ nix run home-manager/$branch -- init --switch
|
||||||
|
```
|
||||||
|
|
||||||
|
Where `$branch` is one of `master` or `release-23.11`.
|
||||||
|
|
||||||
|
After the initial activation has completed successfully then building
|
||||||
|
and activating your flake-based configuration is as simple as
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ home-manager switch
|
||||||
|
```
|
||||||
|
|
||||||
|
It is possible to override the default configuration directory, if you
|
||||||
|
want. For example,
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix run home-manager/$branch -- init --switch ~/hmconf
|
||||||
|
$ # And after the initial activation.
|
||||||
|
$ home-manager switch --flake ~/hmconf
|
||||||
|
```
|
||||||
|
|
||||||
|
::: {.note}
|
||||||
|
The flake inputs are not automatically updated by Home Manager. You need
|
||||||
|
to use the standard `nix flake update` command for that.
|
||||||
|
|
||||||
|
If you only want to update a single flake input, then the command
|
||||||
|
`nix flake lock --update-input <input>` can be used.
|
||||||
|
|
||||||
|
You can also pass flake-related options such as `--recreate-lock-file`
|
||||||
|
or `--update-input <input>` to `home-manager` when building or
|
||||||
|
switching, and these options will be forwarded to `nix build`. See the
|
||||||
|
[NixOS Wiki page](https://nixos.wiki/wiki/Flakes) for details.
|
||||||
|
:::
|
||||||
7
docs/manual/nixos-options.md
Normal file
7
docs/manual/nixos-options.md
Normal file
|
|
@ -0,0 +1,7 @@
|
||||||
|
# NixOS Configuration Options {#ch-nixos-options}
|
||||||
|
|
||||||
|
```{=include=} options
|
||||||
|
id-prefix: nixos-opt-
|
||||||
|
list-id: nixos-options
|
||||||
|
source: @OPTIONS_JSON@
|
||||||
|
```
|
||||||
7
docs/manual/options.md
Normal file
7
docs/manual/options.md
Normal file
|
|
@ -0,0 +1,7 @@
|
||||||
|
# Home Manager Configuration Options {#ch-options}
|
||||||
|
|
||||||
|
```{=include=} options
|
||||||
|
id-prefix: opt-
|
||||||
|
list-id: home-manager-options
|
||||||
|
source: @OPTIONS_JSON@
|
||||||
|
```
|
||||||
20
docs/manual/preface.md
Normal file
20
docs/manual/preface.md
Normal file
|
|
@ -0,0 +1,20 @@
|
||||||
|
# Preface {#preface}
|
||||||
|
|
||||||
|
This manual will eventually describe how to install, use, and extend Home
|
||||||
|
Manager.
|
||||||
|
|
||||||
|
If you encounter problems then please reach out on the IRC channel
|
||||||
|
[#home-manager](https://webchat.oftc.net/?channels=home-manager)
|
||||||
|
hosted by [OFTC](https://oftc.net/).
|
||||||
|
There is also a [Matrix room](https://matrix.to/#/%23hm:rycee.net),
|
||||||
|
which is bridged to the IRC channel.
|
||||||
|
If your problem is caused by a bug in Home Manager then it should
|
||||||
|
be reported on the
|
||||||
|
[Home Manager issue tracker](https://github.com/nix-community/home-manager/issues).
|
||||||
|
|
||||||
|
|
||||||
|
:::{.note}
|
||||||
|
Commands prefixed with `$ sudo` have to be run as root, either
|
||||||
|
requiring to login as root user or temporarily switching to it using
|
||||||
|
`sudo` for example.
|
||||||
|
:::
|
||||||
63
docs/manual/usage.md
Normal file
63
docs/manual/usage.md
Normal file
|
|
@ -0,0 +1,63 @@
|
||||||
|
# Using Home Manager {#ch-usage}
|
||||||
|
|
||||||
|
Your use of Home Manager is centered around the configuration file,
|
||||||
|
which is typically found at `~/.config/home-manager/home.nix` in the
|
||||||
|
standard installation or `~/.config/home-manager/flake.nix` in a Nix
|
||||||
|
flake based installation.
|
||||||
|
|
||||||
|
::: {.note}
|
||||||
|
The default configuration used to be placed in `~/.config/nixpkgs`¸ so
|
||||||
|
you may see references to that elsewhere. The old directory still works
|
||||||
|
but Home Manager will print a warning message when used.
|
||||||
|
:::
|
||||||
|
|
||||||
|
This configuration file can be *built* and *activated*.
|
||||||
|
|
||||||
|
Building a configuration produces a directory in the Nix store that
|
||||||
|
contains all files and programs that should be available in your home
|
||||||
|
directory and Nix user profile, respectively. The build step also checks
|
||||||
|
that the configuration is valid and it will fail with an error if you,
|
||||||
|
for example, assign a value to an option that does not exist or assign a
|
||||||
|
value of the wrong type. Some modules also have custom assertions that
|
||||||
|
perform more detailed, module specific, checks.
|
||||||
|
|
||||||
|
Concretely, if your configuration contains
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
programs.emacs.enable = "yes";
|
||||||
|
```
|
||||||
|
|
||||||
|
then building it, for example using `home-manager build`, will result in
|
||||||
|
an error message saying something like
|
||||||
|
|
||||||
|
```console
|
||||||
|
$ home-manager build
|
||||||
|
error: A definition for option `programs.emacs.enable' is not of type `boolean'. Definition values:
|
||||||
|
- In `/home/jdoe/.config/home-manager/home.nix': "yes"
|
||||||
|
(use '--show-trace' to show detailed location information)
|
||||||
|
```
|
||||||
|
|
||||||
|
The message indicates that you must provide a Boolean value for this
|
||||||
|
option, that is, either `true` or `false`. The documentation of each
|
||||||
|
option will state the expected type, for
|
||||||
|
[programs.emacs.enable](#opt-programs.emacs.enable) you will see "Type: boolean". You
|
||||||
|
there also find information about the default value and a description of
|
||||||
|
the option. You can find the complete option documentation in
|
||||||
|
[Home Manager Configuration Options](#ch-options) or directly in the terminal by running
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
man home-configuration.nix
|
||||||
|
```
|
||||||
|
|
||||||
|
Once a configuration is successfully built, it can be activated. The
|
||||||
|
activation performs the steps necessary to make the files, programs, and
|
||||||
|
services available in your user environment. The `home-manager switch`
|
||||||
|
command performs a combined build and activation.
|
||||||
|
|
||||||
|
```{=include=} sections
|
||||||
|
usage/configuration.md
|
||||||
|
usage/rollbacks.md
|
||||||
|
usage/dotfiles.md
|
||||||
|
usage/graphical.md
|
||||||
|
usage/updating.md
|
||||||
|
```
|
||||||
112
docs/manual/usage/configuration.md
Normal file
112
docs/manual/usage/configuration.md
Normal file
|
|
@ -0,0 +1,112 @@
|
||||||
|
# Configuration Example {#sec-usage-configuration}
|
||||||
|
|
||||||
|
A fresh install of Home Manager will generate a minimal
|
||||||
|
`~/.config/home-manager/home.nix` file containing something like
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
{ config, pkgs, ... }:
|
||||||
|
|
||||||
|
{
|
||||||
|
# Home Manager needs a bit of information about you and the
|
||||||
|
# paths it should manage.
|
||||||
|
home.username = "jdoe";
|
||||||
|
home.homeDirectory = "/home/jdoe";
|
||||||
|
|
||||||
|
# This value determines the Home Manager release that your
|
||||||
|
# configuration is compatible with. This helps avoid breakage
|
||||||
|
# when a new Home Manager release introduces backwards
|
||||||
|
# incompatible changes.
|
||||||
|
#
|
||||||
|
# You can update Home Manager without changing this value. See
|
||||||
|
# the Home Manager release notes for a list of state version
|
||||||
|
# changes in each release.
|
||||||
|
home.stateVersion = "23.11";
|
||||||
|
|
||||||
|
# Let Home Manager install and manage itself.
|
||||||
|
programs.home-manager.enable = true;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
You can use this as a base for your further configurations.
|
||||||
|
|
||||||
|
::: {.note}
|
||||||
|
If you are not very familiar with the Nix language and NixOS modules
|
||||||
|
then it is encouraged to start with small and simple changes. As you
|
||||||
|
learn you can gradually grow the configuration with confidence.
|
||||||
|
:::
|
||||||
|
|
||||||
|
As an example, let us expand the initial configuration file to also
|
||||||
|
install the htop and fortune packages, install Emacs with a few extra
|
||||||
|
packages available, and enable the user gpg-agent service.
|
||||||
|
|
||||||
|
To satisfy the above setup we should elaborate the `home.nix` file as
|
||||||
|
follows:
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
{ config, pkgs, ... }:
|
||||||
|
|
||||||
|
{
|
||||||
|
# Home Manager needs a bit of information about you and the
|
||||||
|
# paths it should manage.
|
||||||
|
home.username = "jdoe";
|
||||||
|
home.homeDirectory = "/home/jdoe";
|
||||||
|
|
||||||
|
# Packages that should be installed to the user profile.
|
||||||
|
home.packages = [
|
||||||
|
pkgs.htop
|
||||||
|
pkgs.fortune
|
||||||
|
];
|
||||||
|
|
||||||
|
# This value determines the Home Manager release that your
|
||||||
|
# configuration is compatible with. This helps avoid breakage
|
||||||
|
# when a new Home Manager release introduces backwards
|
||||||
|
# incompatible changes.
|
||||||
|
#
|
||||||
|
# You can update Home Manager without changing this value. See
|
||||||
|
# the Home Manager release notes for a list of state version
|
||||||
|
# changes in each release.
|
||||||
|
home.stateVersion = "23.11";
|
||||||
|
|
||||||
|
# Let Home Manager install and manage itself.
|
||||||
|
programs.home-manager.enable = true;
|
||||||
|
|
||||||
|
programs.emacs = {
|
||||||
|
enable = true;
|
||||||
|
extraPackages = epkgs: [
|
||||||
|
epkgs.nix-mode
|
||||||
|
epkgs.magit
|
||||||
|
];
|
||||||
|
};
|
||||||
|
|
||||||
|
services.gpg-agent = {
|
||||||
|
enable = true;
|
||||||
|
defaultCacheTtl = 1800;
|
||||||
|
enableSshSupport = true;
|
||||||
|
};
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
- Nixpkgs packages can be installed to the user profile using
|
||||||
|
[???](opt-home.packages).
|
||||||
|
|
||||||
|
- The option names of a program module typically start with
|
||||||
|
`programs.<package name>`.
|
||||||
|
|
||||||
|
- Similarly, for a service module, the names start with
|
||||||
|
`services.<package name>`. Note in some cases a package has both
|
||||||
|
programs *and* service options -- Emacs is such an example.
|
||||||
|
|
||||||
|
To activate this configuration you can run
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
home-manager switch
|
||||||
|
```
|
||||||
|
|
||||||
|
or if you are not feeling so lucky,
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
home-manager build
|
||||||
|
```
|
||||||
|
|
||||||
|
which will create a `result` link to a directory containing an
|
||||||
|
activation script and the generated home directory files.
|
||||||
36
docs/manual/usage/dotfiles.md
Normal file
36
docs/manual/usage/dotfiles.md
Normal file
|
|
@ -0,0 +1,36 @@
|
||||||
|
# Keeping your \~ safe from harm {#sec-usage-dotfiles}
|
||||||
|
|
||||||
|
To configure programs and services Home Manager must write various
|
||||||
|
things to your home directory. To prevent overwriting any existing files
|
||||||
|
when switching to a new generation, Home Manager will attempt to detect
|
||||||
|
collisions between existing files and generated files. If any such
|
||||||
|
collision is detected the activation will terminate before changing
|
||||||
|
anything on your computer.
|
||||||
|
|
||||||
|
For example, suppose you have a wonderful, painstakingly created
|
||||||
|
`~/.config/git/config` and add
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
{
|
||||||
|
# …
|
||||||
|
|
||||||
|
programs.git = {
|
||||||
|
enable = true;
|
||||||
|
userName = "Jane Doe";
|
||||||
|
userEmail = "jane.doe@example.org";
|
||||||
|
};
|
||||||
|
|
||||||
|
# …
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
to your configuration. Attempting to switch to the generation will then
|
||||||
|
result in
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ home-manager switch
|
||||||
|
…
|
||||||
|
Activating checkLinkTargets
|
||||||
|
Existing file '/home/jdoe/.config/git/config' is in the way
|
||||||
|
Please move the above files and try again
|
||||||
|
```
|
||||||
32
docs/manual/usage/graphical.md
Normal file
32
docs/manual/usage/graphical.md
Normal file
|
|
@ -0,0 +1,32 @@
|
||||||
|
# Graphical services {#sec-usage-graphical}
|
||||||
|
|
||||||
|
Home Manager includes a number of services intended to run in a
|
||||||
|
graphical session, for example `xscreensaver` and `dunst`.
|
||||||
|
Unfortunately, such services will not be started automatically unless
|
||||||
|
you let Home Manager start your X session. That is, you have something
|
||||||
|
like
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
{
|
||||||
|
# …
|
||||||
|
|
||||||
|
services.xserver.enable = true;
|
||||||
|
|
||||||
|
# …
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
in your system configuration and
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
{
|
||||||
|
# …
|
||||||
|
|
||||||
|
xsession.enable = true;
|
||||||
|
xsession.windowManager.command = "…";
|
||||||
|
|
||||||
|
# …
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
in your Home Manager configuration.
|
||||||
32
docs/manual/usage/rollbacks.md
Normal file
32
docs/manual/usage/rollbacks.md
Normal file
|
|
@ -0,0 +1,32 @@
|
||||||
|
# Rollbacks {#sec-usage-rollbacks}
|
||||||
|
|
||||||
|
While the `home-manager` tool does not explicitly support rollbacks at
|
||||||
|
the moment it is relatively easy to perform one manually. The steps to
|
||||||
|
do so are
|
||||||
|
|
||||||
|
1. Run `home-manager generations` to determine which generation you
|
||||||
|
wish to rollback to:
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ home-manager generations
|
||||||
|
2018-01-04 11:56 : id 765 -> /nix/store/kahm1rxk77mnvd2l8pfvd4jkkffk5ijk-home-manager-generation
|
||||||
|
2018-01-03 10:29 : id 764 -> /nix/store/2wsmsliqr5yynqkdyjzb1y57pr5q2lsj-home-manager-generation
|
||||||
|
2018-01-01 12:21 : id 763 -> /nix/store/mv960kl9chn2lal5q8lnqdp1ygxngcd1-home-manager-generation
|
||||||
|
2017-12-29 21:03 : id 762 -> /nix/store/6c0k1r03fxckql4vgqcn9ccb616ynb94-home-manager-generation
|
||||||
|
2017-12-25 18:51 : id 761 -> /nix/store/czc5y6vi1rvnkfv83cs3rn84jarcgsgh-home-manager-generation
|
||||||
|
…
|
||||||
|
```
|
||||||
|
|
||||||
|
2. Copy the Nix store path of the generation you chose, e.g.,
|
||||||
|
|
||||||
|
/nix/store/mv960kl9chn2lal5q8lnqdp1ygxngcd1-home-manager-generation
|
||||||
|
|
||||||
|
for generation 763.
|
||||||
|
|
||||||
|
3. Run the `activate` script inside the copied store path:
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ /nix/store/mv960kl9chn2lal5q8lnqdp1ygxngcd1-home-manager-generation/activate
|
||||||
|
Starting home manager activation
|
||||||
|
…
|
||||||
|
```
|
||||||
12
docs/manual/usage/updating.md
Normal file
12
docs/manual/usage/updating.md
Normal file
|
|
@ -0,0 +1,12 @@
|
||||||
|
# Updating {#sec-updating}
|
||||||
|
|
||||||
|
If you have installed Home Manager using the Nix channel method then
|
||||||
|
updating Home Manager is done by first updating the channel. You can
|
||||||
|
then switch to the updated Home Manager environment.
|
||||||
|
|
||||||
|
``` shell
|
||||||
|
$ nix-channel --update
|
||||||
|
…
|
||||||
|
unpacking channels...
|
||||||
|
$ home-manager switch
|
||||||
|
```
|
||||||
13
docs/manual/writing-modules.md
Normal file
13
docs/manual/writing-modules.md
Normal file
|
|
@ -0,0 +1,13 @@
|
||||||
|
# Writing Home Manager Modules {#ch-writing-modules}
|
||||||
|
|
||||||
|
The module system in Home Manager is based entirely on the NixOS module
|
||||||
|
system so we will here only highlight aspects that are specific for Home
|
||||||
|
Manager. For information about the module system as such please refer to
|
||||||
|
the [Writing NixOS
|
||||||
|
Modules](https://nixos.org/nixos/manual/index.html#sec-writing-modules)
|
||||||
|
chapter of the NixOS manual.
|
||||||
|
|
||||||
|
|
||||||
|
```{=include=} sections
|
||||||
|
writing-modules/types.md
|
||||||
|
```
|
||||||
368
docs/manual/writing-modules/types.md
Normal file
368
docs/manual/writing-modules/types.md
Normal file
|
|
@ -0,0 +1,368 @@
|
||||||
|
# Option Types {#sec-option-types}
|
||||||
|
|
||||||
|
Overall the basic option types are the same in Home Manager as NixOS. A
|
||||||
|
few Home Manager options, however, make use of custom types that are
|
||||||
|
worth describing in more detail. These are the option types `dagOf` and
|
||||||
|
`gvariant` that are used, for example, by
|
||||||
|
[programs.ssh.matchBlocks](#opt-programs.ssh.matchBlocks) and [dconf.settings](#opt-dconf.settings).
|
||||||
|
|
||||||
|
[]{#sec-option-types-dag}`hm.types.dagOf`
|
||||||
|
|
||||||
|
: Options of this type have attribute sets as values where each member
|
||||||
|
is a node in a [directed acyclic
|
||||||
|
graph](https://en.wikipedia.org/w/index.php?title=Directed_acyclic_graph&oldid=939656095)
|
||||||
|
(DAG). This allows the attribute set entries to express dependency
|
||||||
|
relations among themselves. This can, for example, be used to
|
||||||
|
control the order of match blocks in a OpenSSH client configuration
|
||||||
|
or the order of activation script blocks in
|
||||||
|
[home.activation](#opt-home.activation).
|
||||||
|
|
||||||
|
A number of functions are provided to create DAG nodes. The
|
||||||
|
functions are shown below with examples using an option `foo.bar` of
|
||||||
|
type `hm.types.dagOf types.int`.
|
||||||
|
|
||||||
|
[]{#sec-option-types-dag-entryAnywhere}`hm.dag.entryAnywhere (value: T) : DagEntry<T>`
|
||||||
|
|
||||||
|
: Indicates that `value` can be placed anywhere within the DAG.
|
||||||
|
This is also the default for plain attribute set entries, that
|
||||||
|
is
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = {
|
||||||
|
a = hm.dag.entryAnywhere 0;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
and
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = {
|
||||||
|
a = 0;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
are equivalent.
|
||||||
|
|
||||||
|
[]{#sec-option-types-dag-entryAfter}`hm.dag.entryAfter (afters: list string) (value: T) : DagEntry<T>`
|
||||||
|
|
||||||
|
: Indicates that `value` must be placed *after* each of the
|
||||||
|
attribute names in the given list. For example
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = {
|
||||||
|
a = 0;
|
||||||
|
b = hm.dag.entryAfter [ "a" ] 1;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
would place `b` after `a` in the graph.
|
||||||
|
|
||||||
|
[]{#sec-option-types-dag-entryBefore}`hm.dag.entryBefore (befores: list string) (value: T) : DagEntry<T>`
|
||||||
|
|
||||||
|
: Indicates that `value` must be placed *before* each of the
|
||||||
|
attribute names in the given list. For example
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = {
|
||||||
|
b = hm.dag.entryBefore [ "a" ] 1;
|
||||||
|
a = 0;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
would place `b` before `a` in the graph.
|
||||||
|
|
||||||
|
[]{#sec-option-types-dag-entryBetween}`hm.dag.entryBetween (befores: list string) (afters: list string) (value: T) : DagEntry<T>`
|
||||||
|
|
||||||
|
: Indicates that `value` must be placed *before* the attribute
|
||||||
|
names in the first list and *after* the attribute names in the
|
||||||
|
second list. For example
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = {
|
||||||
|
a = 0;
|
||||||
|
c = hm.dag.entryBetween [ "b" ] [ "a" ] 2;
|
||||||
|
b = 1;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
would place `c` before `b` and after `a` in the graph.
|
||||||
|
|
||||||
|
There are also a set of functions that generate a DAG from a list.
|
||||||
|
These are convenient when you just want to have a linear list of DAG
|
||||||
|
entries, without having to manually enter the relationship between
|
||||||
|
each entry. Each of these functions take a `tag` as argument and the
|
||||||
|
DAG entries will be named `${tag}-${index}`.
|
||||||
|
|
||||||
|
[]{#sec-option-types-dag-entriesAnywhere}`hm.dag.entriesAnywhere (tag: string) (values: [T]) : Dag<T>`
|
||||||
|
|
||||||
|
: Creates a DAG with the given values with each entry labeled
|
||||||
|
using the given tag. For example
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = hm.dag.entriesAnywhere "a" [ 0 1 ];
|
||||||
|
```
|
||||||
|
|
||||||
|
is equivalent to
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = {
|
||||||
|
a-0 = 0;
|
||||||
|
a-1 = hm.dag.entryAfter [ "a-0" ] 1;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
[]{#sec-option-types-dag-entriesAfter}`hm.dag.entriesAfter (tag: string) (afters: list string) (values: [T]) : Dag<T>`
|
||||||
|
|
||||||
|
: Creates a DAG with the given values with each entry labeled
|
||||||
|
using the given tag. The list of values are placed are placed
|
||||||
|
*after* each of the attribute names in `afters`. For example
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar =
|
||||||
|
{ b = 0; }
|
||||||
|
// hm.dag.entriesAfter "a" [ "b" ] [ 1 2 ];
|
||||||
|
```
|
||||||
|
|
||||||
|
is equivalent to
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = {
|
||||||
|
b = 0;
|
||||||
|
a-0 = hm.dag.entryAfter [ "b" ] 1;
|
||||||
|
a-1 = hm.dag.entryAfter [ "a-0" ] 2;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
[]{#sec-option-types-dag-entriesBefore}`hm.dag.entriesBefore (tag: string) (befores: list string) (values: [T]) : Dag<T>`
|
||||||
|
|
||||||
|
: Creates a DAG with the given values with each entry labeled
|
||||||
|
using the given tag. The list of values are placed *before* each
|
||||||
|
of the attribute names in `befores`. For example
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar =
|
||||||
|
{ b = 0; }
|
||||||
|
// hm.dag.entriesBefore "a" [ "b" ] [ 1 2 ];
|
||||||
|
```
|
||||||
|
|
||||||
|
is equivalent to
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = {
|
||||||
|
b = 0;
|
||||||
|
a-0 = 1;
|
||||||
|
a-1 = hm.dag.entryBetween [ "b" ] [ "a-0" ] 2;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
[]{#sec-option-types-dag-entriesBetween}`hm.dag.entriesBetween (tag: string) (befores: list string) (afters: list string) (values: [T]) : Dag<T>`
|
||||||
|
|
||||||
|
: Creates a DAG with the given values with each entry labeled
|
||||||
|
using the given tag. The list of values are placed *before* each
|
||||||
|
of the attribute names in `befores` and *after* each of the
|
||||||
|
attribute names in `afters`. For example
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar =
|
||||||
|
{ b = 0; c = 3; }
|
||||||
|
// hm.dag.entriesBetween "a" [ "b" ] [ "c" ] [ 1 2 ];
|
||||||
|
```
|
||||||
|
|
||||||
|
is equivalent to
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = {
|
||||||
|
b = 0;
|
||||||
|
c = 3;
|
||||||
|
a-0 = hm.dag.entryAfter [ "c" ] 1;
|
||||||
|
a-1 = hm.dag.entryBetween [ "b" ] [ "a-0" ] 2;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant}`hm.types.gvariant`
|
||||||
|
|
||||||
|
: This type is useful for options representing
|
||||||
|
[GVariant](https://docs.gtk.org/glib/struct.Variant.html#description)
|
||||||
|
values. The type accepts all primitive GVariant types as well as
|
||||||
|
arrays, tuples, "maybe" types, and dictionaries.
|
||||||
|
|
||||||
|
Some Nix values are automatically coerced to matching GVariant value
|
||||||
|
but the GVariant model is richer so you may need to use one of the
|
||||||
|
provided constructor functions. Examples assume an option `foo.bar`
|
||||||
|
of type `hm.types.gvariant`.
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkBoolean}`hm.gvariant.mkBoolean (v: bool)`
|
||||||
|
|
||||||
|
: Takes a Nix value `v` to a GVariant `boolean` value (GVariant
|
||||||
|
format string `b`). Note, Nix booleans are automatically coerced
|
||||||
|
using this function. That is,
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = hm.gvariant.mkBoolean true;
|
||||||
|
```
|
||||||
|
|
||||||
|
is equivalent to
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = true;
|
||||||
|
```
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkString}`hm.gvariant.mkString (v: string)`
|
||||||
|
|
||||||
|
: Takes a Nix value `v` to a GVariant `string` value (GVariant
|
||||||
|
format string `s`). Note, Nix strings are automatically coerced
|
||||||
|
using this function. That is,
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = hm.gvariant.mkString "a string";
|
||||||
|
```
|
||||||
|
|
||||||
|
is equivalent to
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = "a string";
|
||||||
|
```
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkObjectpath}`hm.gvariant.mkObjectpath (v: string)`
|
||||||
|
|
||||||
|
: Takes a Nix value `v` to a GVariant `objectpath` value (GVariant
|
||||||
|
format string `o`).
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkUchar}`hm.gvariant.mkUchar (v: string)`
|
||||||
|
|
||||||
|
: Takes a Nix value `v` to a GVariant `uchar` value (GVariant
|
||||||
|
format string `y`).
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkInt16}`hm.gvariant.mkInt16 (v: int)`
|
||||||
|
|
||||||
|
: Takes a Nix value `v` to a GVariant `int16` value (GVariant
|
||||||
|
format string `n`).
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkUint16}`hm.gvariant.mkUint16 (v: int)`
|
||||||
|
|
||||||
|
: Takes a Nix value `v` to a GVariant `uint16` value (GVariant
|
||||||
|
format string `q`).
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkInt32}`hm.gvariant.mkInt32 (v: int)`
|
||||||
|
|
||||||
|
: Takes a Nix value `v` to a GVariant `int32` value (GVariant
|
||||||
|
format string `i`). Note, Nix integers are automatically coerced
|
||||||
|
using this function. That is,
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = hm.gvariant.mkInt32 7;
|
||||||
|
```
|
||||||
|
|
||||||
|
is equivalent to
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = 7;
|
||||||
|
```
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkUint32}`hm.gvariant.mkUint32 (v: int)`
|
||||||
|
|
||||||
|
: Takes a Nix value `v` to a GVariant `uint32` value (GVariant
|
||||||
|
format string `u`).
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkInt64}`hm.gvariant.mkInt64 (v: int)`
|
||||||
|
|
||||||
|
: Takes a Nix value `v` to a GVariant `int64` value (GVariant
|
||||||
|
format string `x`).
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkUint64}`hm.gvariant.mkUint64 (v: int)`
|
||||||
|
|
||||||
|
: Takes a Nix value `v` to a GVariant `uint64` value (GVariant
|
||||||
|
format string `t`).
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkDouble}`hm.gvariant.mkDouble (v: double)`
|
||||||
|
|
||||||
|
: Takes a Nix value `v` to a GVariant `double` value (GVariant
|
||||||
|
format string `d`). Note, Nix floats are automatically coerced
|
||||||
|
using this function. That is,
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = hm.gvariant.mkDouble 3.14;
|
||||||
|
```
|
||||||
|
|
||||||
|
is equivalent to
|
||||||
|
|
||||||
|
``` nix
|
||||||
|
foo.bar = 3.14;
|
||||||
|
```
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkArray}`hm.gvariant.mkArray type elements`
|
||||||
|
|
||||||
|
: Builds a GVariant array containing the given list of elements,
|
||||||
|
where each element is a GVariant value of the given type
|
||||||
|
(GVariant format string `a${type}`). The `type` value can be
|
||||||
|
constructed using
|
||||||
|
|
||||||
|
- `hm.gvariant.type.string` (GVariant format string `s`)
|
||||||
|
|
||||||
|
- `hm.gvariant.type.boolean` (GVariant format string `b`)
|
||||||
|
|
||||||
|
- `hm.gvariant.type.uchar` (GVariant format string `y`)
|
||||||
|
|
||||||
|
- `hm.gvariant.type.int16` (GVariant format string `n`)
|
||||||
|
|
||||||
|
- `hm.gvariant.type.uint16` (GVariant format string `q`)
|
||||||
|
|
||||||
|
- `hm.gvariant.type.int32` (GVariant format string `i`)
|
||||||
|
|
||||||
|
- `hm.gvariant.type.uint32` (GVariant format string `u`)
|
||||||
|
|
||||||
|
- `hm.gvariant.type.int64` (GVariant format string `x`)
|
||||||
|
|
||||||
|
- `hm.gvariant.type.uint64` (GVariant format string `t`)
|
||||||
|
|
||||||
|
- `hm.gvariant.type.double` (GVariant format string `d`)
|
||||||
|
|
||||||
|
- `hm.gvariant.type.variant` (GVariant format string `v`)
|
||||||
|
|
||||||
|
- `hm.gvariant.type.arrayOf type` (GVariant format string
|
||||||
|
`a${type}`)
|
||||||
|
|
||||||
|
- `hm.gvariant.type.maybeOf type` (GVariant format string
|
||||||
|
`m${type}`)
|
||||||
|
|
||||||
|
- `hm.gvariant.type.tupleOf types` (GVariant format string
|
||||||
|
`(${lib.concatStrings types})`)
|
||||||
|
|
||||||
|
- `hm.gvariant.type.dictionaryEntryOf [keyType valueType]`
|
||||||
|
(GVariant format string `{${keyType}${valueType}}`)
|
||||||
|
|
||||||
|
where `type` and `types` are themselves a type and list of
|
||||||
|
types, respectively.
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkEmptyArray}`hm.gvariant.mkEmptyArray type`
|
||||||
|
|
||||||
|
: An alias of
|
||||||
|
[`hm.gvariant.mkArray type []`](#sec-option-types-gvariant-mkArray).
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkNothing}`hm.gvariant.mkNothing type`
|
||||||
|
|
||||||
|
: Builds a GVariant maybe value (GVariant format string
|
||||||
|
`m${type}`) whose (non-existent) element is of the given type.
|
||||||
|
The `type` value is constructed as described for the
|
||||||
|
[`mkArray`](#sec-option-types-gvariant-mkArray) function above.
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkJust}`hm.gvariant.mkJust element`
|
||||||
|
|
||||||
|
: Builds a GVariant maybe value (GVariant format string
|
||||||
|
`m${element.type}`) containing the given GVariant element.
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkTuple}`hm.gvariant.mkTuple elements`
|
||||||
|
|
||||||
|
: Builds a GVariant tuple containing the given list of elements,
|
||||||
|
where each element is a GVariant value.
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkVariant}`hm.gvariant.mkVariant element`
|
||||||
|
|
||||||
|
: Builds a GVariant variant (GVariant format string `v`) which
|
||||||
|
contains the value of a GVariant element.
|
||||||
|
|
||||||
|
[]{#sec-option-types-gvariant-mkDictionaryEntry}`hm.gvariant.mkDictionaryEntry [key value]`
|
||||||
|
|
||||||
|
: Builds a GVariant dictionary entry containing the given list of
|
||||||
|
elements (GVariant format string `{${key.type}${value.type}}`),
|
||||||
|
where each element is a GVariant value.
|
||||||
|
|
@ -1,228 +0,0 @@
|
||||||
[[ch-nix-flakes]]
|
|
||||||
== Nix Flakes
|
|
||||||
|
|
||||||
:nixos-wiki-flakes: https://nixos.wiki/wiki/Flakes
|
|
||||||
|
|
||||||
Home Manager is compatible with {nixos-wiki-flakes}[Nix Flakes]. But
|
|
||||||
please be aware that the support it is still experimental and may
|
|
||||||
change in backwards incompatible ways.
|
|
||||||
|
|
||||||
Just like in the standard installation you can use the Home Manager
|
|
||||||
flake in three ways:
|
|
||||||
|
|
||||||
1. Using the standalone `home-manager` tool. For platforms other than
|
|
||||||
NixOS and Darwin, this is the only available choice. It is also
|
|
||||||
recommended for people on NixOS or Darwin that want to manage their
|
|
||||||
home directory independently of the system as a whole. See
|
|
||||||
<<sec-flakes-standalone>> for instructions on how to perform this
|
|
||||||
installation.
|
|
||||||
|
|
||||||
2. As a module within a NixOS system configuration. This allows the
|
|
||||||
user profiles to be built together with the system when running
|
|
||||||
`nixos-rebuild`. See <<sec-flakes-nixos-module>> for a description of
|
|
||||||
this setup.
|
|
||||||
|
|
||||||
3. As a module within a {nix-darwin}[nix-darwin] system configuration.
|
|
||||||
This allows the user profiles to be built together with the system
|
|
||||||
when running `darwin-rebuild`. See <<sec-flakes-nix-darwin-module>>
|
|
||||||
for a description of this setup.
|
|
||||||
|
|
||||||
[[sec-flakes-prerequisites]]
|
|
||||||
=== Prerequisites
|
|
||||||
|
|
||||||
* Install Nix 2.4 or later, or have it in `nix-shell`.
|
|
||||||
|
|
||||||
* Enable experimental features `nix-command` and `flakes`.
|
|
||||||
+
|
|
||||||
** When using NixOS, add the following to your `configuration.nix` and rebuild your system.
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
nix = {
|
|
||||||
package = pkgs.nixFlakes;
|
|
||||||
extraOptions = ''
|
|
||||||
experimental-features = nix-command flakes
|
|
||||||
'';
|
|
||||||
};
|
|
||||||
+
|
|
||||||
** If you are not using NixOS, add the following to `nix.conf` (located at `~/.config/nix/` or `/etc/nix/nix.conf`).
|
|
||||||
+
|
|
||||||
[source,bash]
|
|
||||||
experimental-features = nix-command flakes
|
|
||||||
+
|
|
||||||
You may need to restart the Nix daemon with, for example, `sudo systemctl restart nix-daemon.service`.
|
|
||||||
+
|
|
||||||
** Alternatively, you can enable flakes on a per-command basis with the following additional flags to `nix` and `home-manager`:
|
|
||||||
+
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ nix --extra-experimental-features "nix-command flakes" <sub-commands>
|
|
||||||
$ home-manager --extra-experimental-features "nix-command flakes" <sub-commands>
|
|
||||||
----
|
|
||||||
|
|
||||||
* Prepare your Home Manager configuration (`home.nix`).
|
|
||||||
+
|
|
||||||
Unlike the channel-based setup,
|
|
||||||
`home.nix` will be evaluated when the flake is built,
|
|
||||||
so it must be present before bootstrap of Home Manager from the flake.
|
|
||||||
See <<sec-usage-configuration>> for introduction about
|
|
||||||
writing a Home Manager configuration.
|
|
||||||
|
|
||||||
[[sec-flakes-standalone]]
|
|
||||||
=== Standalone setup
|
|
||||||
|
|
||||||
To prepare an initial Home Manager configuration for your logged in user,
|
|
||||||
you can run the Home Manager `init` command directly from its flake.
|
|
||||||
|
|
||||||
For example, if you are using the unstable version of Nixpkgs or NixOS,
|
|
||||||
then to generate and activate a basic configuration run the command
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
$ nix run home-manager/master -- init --switch
|
|
||||||
|
|
||||||
For Nixpkgs or NixOS version 23.11 run
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
$ nix run home-manager/release-23.11 -- init --switch
|
|
||||||
|
|
||||||
This will generate a `flake.nix` and a `home.nix` file in
|
|
||||||
`~/.config/home-manager`, creating the directory if it does not exist.
|
|
||||||
|
|
||||||
If you omit the `--switch` option then the activation will not happen.
|
|
||||||
This is useful if you want to inspect and edit the configuration before activating it.
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ nix run home-manager/$branch -- init
|
|
||||||
$ # Edit files in ~/.config/home-manager
|
|
||||||
$ nix run home-manager/$branch -- init --switch
|
|
||||||
----
|
|
||||||
|
|
||||||
Where `$branch` is one of `master` or `release-23.11`.
|
|
||||||
|
|
||||||
After the initial activation has completed successfully then building
|
|
||||||
and activating your flake-based configuration is as simple as
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
$ home-manager switch
|
|
||||||
|
|
||||||
It is possible to override the default configuration directory, if you want.
|
|
||||||
For example,
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ nix run home-manager/$branch -- init --switch ~/hmconf
|
|
||||||
$ # And after the initial activation.
|
|
||||||
$ home-manager switch --flake ~/hmconf
|
|
||||||
----
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
====
|
|
||||||
The flake inputs are not automatically updated by Home Manager.
|
|
||||||
You need to use the standard `nix flake update` command for that.
|
|
||||||
|
|
||||||
If you only want to update a single flake input,
|
|
||||||
then the command `nix flake lock --update-input <input>` can be used.
|
|
||||||
|
|
||||||
You can also pass flake-related options
|
|
||||||
such as `--recreate-lock-file` or `--update-input <input>`
|
|
||||||
to `home-manager` when building or switching,
|
|
||||||
and these options will be forwarded to `nix build`.
|
|
||||||
See the {nixos-wiki-flakes}[NixOS Wiki page] for details.
|
|
||||||
====
|
|
||||||
|
|
||||||
[[sec-flakes-nixos-module]]
|
|
||||||
=== NixOS module
|
|
||||||
|
|
||||||
To use Home Manager as a NixOS module,
|
|
||||||
a bare-minimum `flake.nix` would be as follows:
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
{
|
|
||||||
description = "NixOS configuration";
|
|
||||||
|
|
||||||
inputs = {
|
|
||||||
nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
|
|
||||||
home-manager.url = "github:nix-community/home-manager";
|
|
||||||
home-manager.inputs.nixpkgs.follows = "nixpkgs";
|
|
||||||
};
|
|
||||||
|
|
||||||
outputs = inputs@{ nixpkgs, home-manager, ... }: {
|
|
||||||
nixosConfigurations = {
|
|
||||||
hostname = nixpkgs.lib.nixosSystem {
|
|
||||||
system = "x86_64-linux";
|
|
||||||
modules = [
|
|
||||||
./configuration.nix
|
|
||||||
home-manager.nixosModules.home-manager
|
|
||||||
{
|
|
||||||
home-manager.useGlobalPkgs = true;
|
|
||||||
home-manager.useUserPackages = true;
|
|
||||||
home-manager.users.jdoe = import ./home.nix;
|
|
||||||
|
|
||||||
# Optionally, use home-manager.extraSpecialArgs to pass
|
|
||||||
# arguments to home.nix
|
|
||||||
}
|
|
||||||
];
|
|
||||||
};
|
|
||||||
};
|
|
||||||
};
|
|
||||||
}
|
|
||||||
----
|
|
||||||
|
|
||||||
The Home Manager configuration is then part of the NixOS configuration
|
|
||||||
and is automatically rebuilt with the system when using the appropriate command
|
|
||||||
for the system, such as `nixos-rebuild switch --flake <flake-uri>`.
|
|
||||||
|
|
||||||
You can use the above `flake.nix` as a template in `/etc/nixos` by
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
$ nix flake new /etc/nixos -t github:nix-community/home-manager#nixos
|
|
||||||
|
|
||||||
[[sec-flakes-nix-darwin-module]]
|
|
||||||
=== nix-darwin module
|
|
||||||
|
|
||||||
The flake-based setup of the Home Manager nix-darwin module
|
|
||||||
is similar to that of NixOS. The `flake.nix` would be:
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
{
|
|
||||||
description = "Darwin configuration";
|
|
||||||
|
|
||||||
inputs = {
|
|
||||||
nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
|
|
||||||
darwin.url = "github:lnl7/nix-darwin";
|
|
||||||
darwin.inputs.nixpkgs.follows = "nixpkgs";
|
|
||||||
home-manager.url = "github:nix-community/home-manager";
|
|
||||||
home-manager.inputs.nixpkgs.follows = "nixpkgs";
|
|
||||||
};
|
|
||||||
|
|
||||||
outputs = inputs@{ nixpkgs, home-manager, darwin, ... }: {
|
|
||||||
darwinConfigurations = {
|
|
||||||
hostname = darwin.lib.darwinSystem {
|
|
||||||
system = "x86_64-darwin";
|
|
||||||
modules = [
|
|
||||||
./configuration.nix
|
|
||||||
home-manager.darwinModules.home-manager
|
|
||||||
{
|
|
||||||
home-manager.useGlobalPkgs = true;
|
|
||||||
home-manager.useUserPackages = true;
|
|
||||||
home-manager.users.jdoe = import ./home.nix;
|
|
||||||
|
|
||||||
# Optionally, use home-manager.extraSpecialArgs to pass
|
|
||||||
# arguments to home.nix
|
|
||||||
}
|
|
||||||
];
|
|
||||||
};
|
|
||||||
};
|
|
||||||
};
|
|
||||||
}
|
|
||||||
----
|
|
||||||
|
|
||||||
and it is also rebuilt with the nix-darwin generations.
|
|
||||||
The rebuild command here may be `darwin-rebuild switch --flake <flake-uri>`.
|
|
||||||
|
|
||||||
You can use the above `flake.nix` as a template in `~/.config/darwin` by
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
$ nix flake new ~/.config/darwin -t github:nix-community/home-manager#nix-darwin
|
|
||||||
252
docs/usage.adoc
252
docs/usage.adoc
|
|
@ -1,252 +0,0 @@
|
||||||
[[ch-usage]]
|
|
||||||
== Using Home Manager
|
|
||||||
|
|
||||||
Your use of Home Manager is centered around the configuration file,
|
|
||||||
which is typically found at `~/.config/home-manager/home.nix` in the standard installation
|
|
||||||
or `~/.config/home-manager/flake.nix` in a Nix flake based installation.
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
The default configuration used to be placed in `~/.config/nixpkgs`¸
|
|
||||||
so you may see references to that elsewhere.
|
|
||||||
The old directory still works but Home Manager will print a warning message when used.
|
|
||||||
|
|
||||||
This configuration file can be _built_ and _activated_.
|
|
||||||
|
|
||||||
Building a configuration produces a directory in the Nix store that contains all files and programs that should be available in your home directory and Nix user profile, respectively. The build step also checks that the configuration is valid and it will fail with an error if you, for example, assign a value to an option that does not exist or assign a value of the wrong type. Some modules also have custom assertions that perform more detailed, module specific, checks.
|
|
||||||
|
|
||||||
Concretely, if your configuration contains
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
programs.emacs.enable = "yes";
|
|
||||||
|
|
||||||
then building it, for example using `home-manager build`, will result in an error message saying something like
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ home-manager build
|
|
||||||
error: A definition for option `programs.emacs.enable' is not of type `boolean'. Definition values:
|
|
||||||
- In `/home/jdoe/.config/home-manager/home.nix': "yes"
|
|
||||||
(use '--show-trace' to show detailed location information)
|
|
||||||
----
|
|
||||||
|
|
||||||
The message indicates that you must provide a Boolean value for this option, that is, either `true` or `false`. The documentation of each option will state the expected type, for <<opt-programs.emacs.enable>> you will see ``Type: boolean''. You there also find information about the default value and a description of the option. You can find the complete option documentation in <<ch-options>> or directly in the terminal by running
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
man home-configuration.nix
|
|
||||||
|
|
||||||
Once a configuration is successfully built, it can be activated. The activation performs the steps necessary to make the files, programs, and services available in your user environment. The `home-manager switch` command performs a combined build and activation.
|
|
||||||
|
|
||||||
[[sec-usage-configuration]]
|
|
||||||
=== Configuration Example
|
|
||||||
|
|
||||||
A fresh install of Home Manager will generate a minimal `~/.config/home-manager/home.nix` file containing something like
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
{ config, pkgs, ... }:
|
|
||||||
|
|
||||||
{
|
|
||||||
# Home Manager needs a bit of information about you and the
|
|
||||||
# paths it should manage.
|
|
||||||
home.username = "jdoe";
|
|
||||||
home.homeDirectory = "/home/jdoe";
|
|
||||||
|
|
||||||
# This value determines the Home Manager release that your
|
|
||||||
# configuration is compatible with. This helps avoid breakage
|
|
||||||
# when a new Home Manager release introduces backwards
|
|
||||||
# incompatible changes.
|
|
||||||
#
|
|
||||||
# You can update Home Manager without changing this value. See
|
|
||||||
# the Home Manager release notes for a list of state version
|
|
||||||
# changes in each release.
|
|
||||||
home.stateVersion = "23.11";
|
|
||||||
|
|
||||||
# Let Home Manager install and manage itself.
|
|
||||||
programs.home-manager.enable = true;
|
|
||||||
}
|
|
||||||
----
|
|
||||||
|
|
||||||
You can use this as a base for your further configurations.
|
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
If you are not very familiar with the Nix language and NixOS modules then it is encouraged to start with small and simple changes. As you learn you can gradually grow the configuration with confidence.
|
|
||||||
|
|
||||||
As an example, let us expand the initial configuration file to also install the htop and fortune packages, install Emacs with a few extra packages available, and enable the user gpg-agent service.
|
|
||||||
|
|
||||||
To satisfy the above setup we should elaborate the `home.nix` file as follows:
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
{ config, pkgs, ... }:
|
|
||||||
|
|
||||||
{
|
|
||||||
# Home Manager needs a bit of information about you and the
|
|
||||||
# paths it should manage.
|
|
||||||
home.username = "jdoe";
|
|
||||||
home.homeDirectory = "/home/jdoe";
|
|
||||||
|
|
||||||
# Packages that should be installed to the user profile.
|
|
||||||
home.packages = [ <1>
|
|
||||||
pkgs.htop
|
|
||||||
pkgs.fortune
|
|
||||||
];
|
|
||||||
|
|
||||||
# This value determines the Home Manager release that your
|
|
||||||
# configuration is compatible with. This helps avoid breakage
|
|
||||||
# when a new Home Manager release introduces backwards
|
|
||||||
# incompatible changes.
|
|
||||||
#
|
|
||||||
# You can update Home Manager without changing this value. See
|
|
||||||
# the Home Manager release notes for a list of state version
|
|
||||||
# changes in each release.
|
|
||||||
home.stateVersion = "23.11";
|
|
||||||
|
|
||||||
# Let Home Manager install and manage itself.
|
|
||||||
programs.home-manager.enable = true;
|
|
||||||
|
|
||||||
programs.emacs = { <2>
|
|
||||||
enable = true;
|
|
||||||
extraPackages = epkgs: [
|
|
||||||
epkgs.nix-mode
|
|
||||||
epkgs.magit
|
|
||||||
];
|
|
||||||
};
|
|
||||||
|
|
||||||
services.gpg-agent = { <3>
|
|
||||||
enable = true;
|
|
||||||
defaultCacheTtl = 1800;
|
|
||||||
enableSshSupport = true;
|
|
||||||
};
|
|
||||||
}
|
|
||||||
----
|
|
||||||
<1> Nixpkgs packages can be installed to the user profile using <<opt-home.packages>>.
|
|
||||||
<2> The option names of a program module typically start with `programs.<package name>`.
|
|
||||||
<3> Similarly, for a service module, the names start with `services.<package name>`. Note in some cases a package has both programs _and_ service options – Emacs is such an example.
|
|
||||||
|
|
||||||
To activate this configuration you can run
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
home-manager switch
|
|
||||||
|
|
||||||
or if you are not feeling so lucky,
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
home-manager build
|
|
||||||
|
|
||||||
which will create a `result` link to a directory containing an
|
|
||||||
activation script and the generated home directory files.
|
|
||||||
|
|
||||||
[[sec-usage-rollbacks]]
|
|
||||||
=== Rollbacks
|
|
||||||
|
|
||||||
While the `home-manager` tool does not explicitly support rollbacks at the moment it is relatively easy to perform one manually. The steps to do so are
|
|
||||||
|
|
||||||
1. Run `home-manager generations` to determine which generation you wish to rollback to:
|
|
||||||
+
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ home-manager generations
|
|
||||||
2018-01-04 11:56 : id 765 -> /nix/store/kahm1rxk77mnvd2l8pfvd4jkkffk5ijk-home-manager-generation
|
|
||||||
2018-01-03 10:29 : id 764 -> /nix/store/2wsmsliqr5yynqkdyjzb1y57pr5q2lsj-home-manager-generation
|
|
||||||
2018-01-01 12:21 : id 763 -> /nix/store/mv960kl9chn2lal5q8lnqdp1ygxngcd1-home-manager-generation
|
|
||||||
2017-12-29 21:03 : id 762 -> /nix/store/6c0k1r03fxckql4vgqcn9ccb616ynb94-home-manager-generation
|
|
||||||
2017-12-25 18:51 : id 761 -> /nix/store/czc5y6vi1rvnkfv83cs3rn84jarcgsgh-home-manager-generation
|
|
||||||
…
|
|
||||||
----
|
|
||||||
|
|
||||||
2. Copy the Nix store path of the generation you chose, e.g.,
|
|
||||||
+
|
|
||||||
----
|
|
||||||
/nix/store/mv960kl9chn2lal5q8lnqdp1ygxngcd1-home-manager-generation
|
|
||||||
----
|
|
||||||
+
|
|
||||||
for generation 763.
|
|
||||||
|
|
||||||
3. Run the `activate` script inside the copied store path:
|
|
||||||
+
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ /nix/store/mv960kl9chn2lal5q8lnqdp1ygxngcd1-home-manager-generation/activate
|
|
||||||
Starting home manager activation
|
|
||||||
…
|
|
||||||
----
|
|
||||||
|
|
||||||
[[sec-usage-dotfiles]]
|
|
||||||
=== Keeping your ~ safe from harm
|
|
||||||
|
|
||||||
To configure programs and services Home Manager must write various things to your home directory. To prevent overwriting any existing files when switching to a new generation, Home Manager will attempt to detect collisions between existing files and generated files. If any such collision is detected the activation will terminate before changing anything on your computer.
|
|
||||||
|
|
||||||
For example, suppose you have a wonderful, painstakingly created `~/.config/git/config` and add
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
{
|
|
||||||
# …
|
|
||||||
|
|
||||||
programs.git = {
|
|
||||||
enable = true;
|
|
||||||
userName = "Jane Doe";
|
|
||||||
userEmail = "jane.doe@example.org";
|
|
||||||
};
|
|
||||||
|
|
||||||
# …
|
|
||||||
}
|
|
||||||
----
|
|
||||||
|
|
||||||
to your configuration. Attempting to switch to the generation will then result in
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ home-manager switch
|
|
||||||
…
|
|
||||||
Activating checkLinkTargets
|
|
||||||
Existing file '/home/jdoe/.config/git/config' is in the way
|
|
||||||
Please move the above files and try again
|
|
||||||
----
|
|
||||||
|
|
||||||
[[sec-usage-graphical]]
|
|
||||||
=== Graphical services
|
|
||||||
|
|
||||||
Home Manager includes a number of services intended to run in a graphical session, for example `xscreensaver` and `dunst`. Unfortunately, such services will not be started automatically unless you let Home Manager start your X session. That is, you have something like
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
{
|
|
||||||
# …
|
|
||||||
|
|
||||||
services.xserver.enable = true;
|
|
||||||
|
|
||||||
# …
|
|
||||||
}
|
|
||||||
----
|
|
||||||
|
|
||||||
in your system configuration and
|
|
||||||
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
{
|
|
||||||
# …
|
|
||||||
|
|
||||||
xsession.enable = true;
|
|
||||||
xsession.windowManager.command = "…";
|
|
||||||
|
|
||||||
# …
|
|
||||||
}
|
|
||||||
----
|
|
||||||
|
|
||||||
in your Home Manager configuration.
|
|
||||||
|
|
||||||
[[sec-updating]]
|
|
||||||
=== Updating
|
|
||||||
|
|
||||||
If you have installed Home Manager using the Nix channel method
|
|
||||||
then updating Home Manager is done by first updating the channel.
|
|
||||||
You can then switch to the updated Home Manager environment.
|
|
||||||
|
|
||||||
[source,console]
|
|
||||||
----
|
|
||||||
$ nix-channel --update
|
|
||||||
…
|
|
||||||
unpacking channels...
|
|
||||||
$ home-manager switch
|
|
||||||
----
|
|
||||||
|
|
@ -1,283 +0,0 @@
|
||||||
[[ch-writing-modules]]
|
|
||||||
== Writing Home Manager Modules
|
|
||||||
:writing-nixos-modules: https://nixos.org/nixos/manual/index.html#sec-writing-modules
|
|
||||||
|
|
||||||
The module system in Home Manager is based entirely on the NixOS module system so we will here only highlight aspects that are specific for Home Manager. For information about the module system as such please refer to the {writing-nixos-modules}[Writing NixOS Modules] chapter of the NixOS manual.
|
|
||||||
|
|
||||||
[[sec-option-types]]
|
|
||||||
=== Option Types
|
|
||||||
:wikipedia-dag: https://en.wikipedia.org/w/index.php?title=Directed_acyclic_graph&oldid=939656095
|
|
||||||
:gvariant-description: https://docs.gtk.org/glib/struct.Variant.html#description
|
|
||||||
|
|
||||||
Overall the basic option types are the same in Home Manager as NixOS. A few Home Manager options, however, make use of custom types that are worth describing in more detail. These are the option types `dagOf` and `gvariant` that are used, for example, by <<opt-programs.ssh.matchBlocks>> and <<opt-dconf.settings>>.
|
|
||||||
|
|
||||||
[[sec-option-types-dag]]`hm.types.dagOf`::
|
|
||||||
Options of this type have attribute sets as values where each member is a node in a {wikipedia-dag}[directed acyclic graph] (DAG). This allows the attribute set entries to express dependency relations among themselves. This can, for example, be used to control the order of match blocks in a OpenSSH client configuration or the order of activation script blocks in <<opt-home.activation>>.
|
|
||||||
+
|
|
||||||
A number of functions are provided to create DAG nodes. The functions are shown below with examples using an option `foo.bar` of type `hm.types.dagOf types.int`.
|
|
||||||
+
|
|
||||||
--
|
|
||||||
[[sec-option-types-dag-entryAnywhere]]`hm.dag.entryAnywhere (value: T) : DagEntry<T>`:::
|
|
||||||
Indicates that `value` can be placed anywhere within the DAG. This is also the default for plain attribute set entries, that is
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = {
|
|
||||||
a = hm.dag.entryAnywhere 0;
|
|
||||||
}
|
|
||||||
----
|
|
||||||
+
|
|
||||||
and
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = {
|
|
||||||
a = 0;
|
|
||||||
}
|
|
||||||
----
|
|
||||||
+
|
|
||||||
are equivalent.
|
|
||||||
+
|
|
||||||
[[sec-option-types-dag-entryAfter]]`hm.dag.entryAfter (afters: list string) (value: T) : DagEntry<T>` :::
|
|
||||||
Indicates that `value` must be placed _after_ each of the attribute names in the given list. For example
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = {
|
|
||||||
a = 0;
|
|
||||||
b = hm.dag.entryAfter [ "a" ] 1;
|
|
||||||
}
|
|
||||||
----
|
|
||||||
+
|
|
||||||
would place `b` after `a` in the graph.
|
|
||||||
+
|
|
||||||
[[sec-option-types-dag-entryBefore]]`hm.dag.entryBefore (befores: list string) (value: T) : DagEntry<T>` :::
|
|
||||||
Indicates that `value` must be placed _before_ each of the attribute names in the given list. For example
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = {
|
|
||||||
b = hm.dag.entryBefore [ "a" ] 1;
|
|
||||||
a = 0;
|
|
||||||
}
|
|
||||||
----
|
|
||||||
+
|
|
||||||
would place `b` before `a` in the graph.
|
|
||||||
+
|
|
||||||
[[sec-option-types-dag-entryBetween]]`hm.dag.entryBetween (befores: list string) (afters: list string) (value: T) : DagEntry<T>` :::
|
|
||||||
Indicates that `value` must be placed _before_ the attribute names in the first list and _after_ the attribute names in the second list. For example
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = {
|
|
||||||
a = 0;
|
|
||||||
c = hm.dag.entryBetween [ "b" ] [ "a" ] 2;
|
|
||||||
b = 1;
|
|
||||||
}
|
|
||||||
----
|
|
||||||
+
|
|
||||||
would place `c` before `b` and after `a` in the graph.
|
|
||||||
--
|
|
||||||
+
|
|
||||||
There are also a set of functions that generate a DAG from a list.
|
|
||||||
These are convenient when you just want to have a linear list of DAG entries,
|
|
||||||
without having to manually enter the relationship between each entry.
|
|
||||||
Each of these functions take a `tag` as argument and the DAG entries will be named `${tag}-${index}`.
|
|
||||||
|
|
||||||
[[sec-option-types-dag-entriesAnywhere]]`hm.dag.entriesAnywhere (tag: string) (values: [T]) : Dag<T>`:::
|
|
||||||
Creates a DAG with the given values with each entry labeled using the given tag. For example
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
foo.bar = hm.dag.entriesAnywhere "a" [ 0 1 ];
|
|
||||||
+
|
|
||||||
is equivalent to
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = {
|
|
||||||
a-0 = 0;
|
|
||||||
a-1 = hm.dag.entryAfter [ "a-0" ] 1;
|
|
||||||
}
|
|
||||||
----
|
|
||||||
+
|
|
||||||
[[sec-option-types-dag-entriesAfter]]`hm.dag.entriesAfter (tag: string) (afters: list string) (values: [T]) : Dag<T>`:::
|
|
||||||
Creates a DAG with the given values with each entry labeled using the given tag.
|
|
||||||
The list of values are placed are placed _after_ each of the attribute names in `afters`.
|
|
||||||
For example
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
foo.bar =
|
|
||||||
{ b = 0; }
|
|
||||||
// hm.dag.entriesAfter "a" [ "b" ] [ 1 2 ];
|
|
||||||
+
|
|
||||||
is equivalent to
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = {
|
|
||||||
b = 0;
|
|
||||||
a-0 = hm.dag.entryAfter [ "b" ] 1;
|
|
||||||
a-1 = hm.dag.entryAfter [ "a-0" ] 2;
|
|
||||||
}
|
|
||||||
----
|
|
||||||
+
|
|
||||||
[[sec-option-types-dag-entriesBefore]]`hm.dag.entriesBefore (tag: string) (befores: list string) (values: [T]) : Dag<T>`:::
|
|
||||||
Creates a DAG with the given values with each entry labeled using the given tag.
|
|
||||||
The list of values are placed _before_ each of the attribute names in `befores`.
|
|
||||||
For example
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
foo.bar =
|
|
||||||
{ b = 0; }
|
|
||||||
// hm.dag.entriesBefore "a" [ "b" ] [ 1 2 ];
|
|
||||||
+
|
|
||||||
is equivalent to
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = {
|
|
||||||
b = 0;
|
|
||||||
a-0 = 1;
|
|
||||||
a-1 = hm.dag.entryBetween [ "b" ] [ "a-0" ] 2;
|
|
||||||
}
|
|
||||||
----
|
|
||||||
+
|
|
||||||
[[sec-option-types-dag-entriesBetween]]`hm.dag.entriesBetween (tag: string) (befores: list string) (afters: list string) (values: [T]) : Dag<T>`:::
|
|
||||||
Creates a DAG with the given values with each entry labeled using the given tag.
|
|
||||||
The list of values are placed _before_ each of the attribute names in `befores`
|
|
||||||
and _after_ each of the attribute names in `afters`.
|
|
||||||
For example
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
foo.bar =
|
|
||||||
{ b = 0; c = 3; }
|
|
||||||
// hm.dag.entriesBetween "a" [ "b" ] [ "c" ] [ 1 2 ];
|
|
||||||
+
|
|
||||||
is equivalent to
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = {
|
|
||||||
b = 0;
|
|
||||||
c = 3;
|
|
||||||
a-0 = hm.dag.entryAfter [ "c" ] 1;
|
|
||||||
a-1 = hm.dag.entryBetween [ "b" ] [ "a-0" ] 2;
|
|
||||||
}
|
|
||||||
----
|
|
||||||
|
|
||||||
[[sec-option-types-gvariant]]`hm.types.gvariant`::
|
|
||||||
This type is useful for options representing {gvariant-description}[GVariant] values. The type accepts all primitive GVariant types as well as arrays, tuples, ``maybe'' types, and dictionaries.
|
|
||||||
+
|
|
||||||
Some Nix values are automatically coerced to matching GVariant value but the GVariant model is richer so you may need to use one of the provided constructor functions. Examples assume an option `foo.bar` of type `hm.types.gvariant`.
|
|
||||||
+
|
|
||||||
[[sec-option-types-gvariant-mkBoolean]]`hm.gvariant.mkBoolean (v: bool)`:::
|
|
||||||
Takes a Nix value `v` to a GVariant `boolean` value (GVariant format string `b`). Note, Nix booleans are automatically coerced using this function. That is,
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = hm.gvariant.mkBoolean true;
|
|
||||||
----
|
|
||||||
+
|
|
||||||
is equivalent to
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = true;
|
|
||||||
----
|
|
||||||
[[sec-option-types-gvariant-mkString]]`hm.gvariant.mkString (v: string)`:::
|
|
||||||
Takes a Nix value `v` to a GVariant `string` value (GVariant format string `s`). Note, Nix strings are automatically coerced using this function. That is,
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = hm.gvariant.mkString "a string";
|
|
||||||
----
|
|
||||||
+
|
|
||||||
is equivalent to
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = "a string";
|
|
||||||
----
|
|
||||||
[[sec-option-types-gvariant-mkObjectpath]]`hm.gvariant.mkObjectpath (v: string)`:::
|
|
||||||
Takes a Nix value `v` to a GVariant `objectpath` value (GVariant format string `o`).
|
|
||||||
[[sec-option-types-gvariant-mkUchar]]`hm.gvariant.mkUchar (v: string)`:::
|
|
||||||
Takes a Nix value `v` to a GVariant `uchar` value (GVariant format string `y`).
|
|
||||||
[[sec-option-types-gvariant-mkInt16]]`hm.gvariant.mkInt16 (v: int)`:::
|
|
||||||
Takes a Nix value `v` to a GVariant `int16` value (GVariant format string `n`).
|
|
||||||
[[sec-option-types-gvariant-mkUint16]]`hm.gvariant.mkUint16 (v: int)`:::
|
|
||||||
Takes a Nix value `v` to a GVariant `uint16` value (GVariant format string `q`).
|
|
||||||
[[sec-option-types-gvariant-mkInt32]]`hm.gvariant.mkInt32 (v: int)`:::
|
|
||||||
Takes a Nix value `v` to a GVariant `int32` value (GVariant format string `i`). Note, Nix integers are automatically coerced using this function. That is,
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = hm.gvariant.mkInt32 7;
|
|
||||||
----
|
|
||||||
+
|
|
||||||
is equivalent to
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = 7;
|
|
||||||
----
|
|
||||||
[[sec-option-types-gvariant-mkUint32]]`hm.gvariant.mkUint32 (v: int)`:::
|
|
||||||
Takes a Nix value `v` to a GVariant `uint32` value (GVariant format string `u`).
|
|
||||||
[[sec-option-types-gvariant-mkInt64]]`hm.gvariant.mkInt64 (v: int)`:::
|
|
||||||
Takes a Nix value `v` to a GVariant `int64` value (GVariant format string `x`).
|
|
||||||
[[sec-option-types-gvariant-mkUint64]]`hm.gvariant.mkUint64 (v: int)`:::
|
|
||||||
Takes a Nix value `v` to a GVariant `uint64` value (GVariant format string `t`).
|
|
||||||
[[sec-option-types-gvariant-mkDouble]]`hm.gvariant.mkDouble (v: double)`:::
|
|
||||||
Takes a Nix value `v` to a GVariant `double` value (GVariant format string `d`). Note, Nix floats are automatically coerced using this function. That is,
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = hm.gvariant.mkDouble 3.14;
|
|
||||||
----
|
|
||||||
+
|
|
||||||
is equivalent to
|
|
||||||
+
|
|
||||||
[source,nix]
|
|
||||||
----
|
|
||||||
foo.bar = 3.14;
|
|
||||||
----
|
|
||||||
+
|
|
||||||
[[sec-option-types-gvariant-mkArray]]`hm.gvariant.mkArray type elements`:::
|
|
||||||
Builds a GVariant array containing the given list of elements, where each element is a GVariant value of the given type (GVariant format string `a${type}`). The `type` value can be constructed using
|
|
||||||
+
|
|
||||||
--
|
|
||||||
- `hm.gvariant.type.string` (GVariant format string `s`)
|
|
||||||
- `hm.gvariant.type.boolean` (GVariant format string `b`)
|
|
||||||
- `hm.gvariant.type.uchar` (GVariant format string `y`)
|
|
||||||
- `hm.gvariant.type.int16` (GVariant format string `n`)
|
|
||||||
- `hm.gvariant.type.uint16` (GVariant format string `q`)
|
|
||||||
- `hm.gvariant.type.int32` (GVariant format string `i`)
|
|
||||||
- `hm.gvariant.type.uint32` (GVariant format string `u`)
|
|
||||||
- `hm.gvariant.type.int64` (GVariant format string `x`)
|
|
||||||
- `hm.gvariant.type.uint64` (GVariant format string `t`)
|
|
||||||
- `hm.gvariant.type.double` (GVariant format string `d`)
|
|
||||||
- `hm.gvariant.type.variant` (GVariant format string `v`)
|
|
||||||
- `hm.gvariant.type.arrayOf type` (GVariant format string `a${type}`)
|
|
||||||
- `hm.gvariant.type.maybeOf type` (GVariant format string `m${type}`)
|
|
||||||
- `hm.gvariant.type.tupleOf types` (GVariant format string `(${lib.concatStrings types})`)
|
|
||||||
- `hm.gvariant.type.dictionaryEntryOf [keyType valueType]` (GVariant format string `{${keyType}${valueType}}`)
|
|
||||||
--
|
|
||||||
+
|
|
||||||
where `type` and `types` are themselves a type and list of types, respectively.
|
|
||||||
+
|
|
||||||
[[sec-option-types-gvariant-mkEmptyArray]]`hm.gvariant.mkEmptyArray type`:::
|
|
||||||
An alias of <<sec-option-types-gvariant-mkArray,`hm.gvariant.mkArray type []`>>.
|
|
||||||
+
|
|
||||||
[[sec-option-types-gvariant-mkNothing]]`hm.gvariant.mkNothing type`:::
|
|
||||||
Builds a GVariant maybe value (GVariant format string `m${type}`) whose (non-existent) element is of the given type. The `type` value is constructed as described for the <<sec-option-types-gvariant-mkArray,`mkArray`>> function above.
|
|
||||||
+
|
|
||||||
[[sec-option-types-gvariant-mkJust]]`hm.gvariant.mkJust element`:::
|
|
||||||
Builds a GVariant maybe value (GVariant format string `m${element.type}`) containing the given GVariant element.
|
|
||||||
+
|
|
||||||
[[sec-option-types-gvariant-mkTuple]]`hm.gvariant.mkTuple elements`:::
|
|
||||||
Builds a GVariant tuple containing the given list of elements, where each element is a GVariant value.
|
|
||||||
+
|
|
||||||
[[sec-option-types-gvariant-mkVariant]]`hm.gvariant.mkVariant element`:::
|
|
||||||
Builds a GVariant variant (GVariant format string `v`) which contains the value of a GVariant element.
|
|
||||||
+
|
|
||||||
[[sec-option-types-gvariant-mkDictionaryEntry]]`hm.gvariant.mkDictionaryEntry [key value]`:::
|
|
||||||
Builds a GVariant dictionary entry containing the given list of elements (GVariant format string `{${key.type}${value.type}}`), where each element is a GVariant value.
|
|
||||||
|
|
@ -2,11 +2,11 @@
|
||||||
"nodes": {
|
"nodes": {
|
||||||
"nixpkgs": {
|
"nixpkgs": {
|
||||||
"locked": {
|
"locked": {
|
||||||
"lastModified": 1701253981,
|
"lastModified": 1701718080,
|
||||||
"narHash": "sha256-ztaDIyZ7HrTAfEEUt9AtTDNoCYxUdSd6NrRHaYOIxtk=",
|
"narHash": "sha256-6ovz0pG76dE0P170pmmZex1wWcQoeiomUZGggfH9XPs=",
|
||||||
"owner": "NixOS",
|
"owner": "NixOS",
|
||||||
"repo": "nixpkgs",
|
"repo": "nixpkgs",
|
||||||
"rev": "e92039b55bcd58469325ded85d4f58dd5a4eaf58",
|
"rev": "2c7f3c0fb7c08a0814627611d9d7d45ab6d75335",
|
||||||
"type": "github"
|
"type": "github"
|
||||||
},
|
},
|
||||||
"original": {
|
"original": {
|
||||||
|
|
|
||||||
|
|
@ -9,11 +9,11 @@
|
||||||
};
|
};
|
||||||
|
|
||||||
nmt.script = ''
|
nmt.script = ''
|
||||||
assertFileExists home-path/share/doc/home-manager/index.html
|
assertFileExists home-path/share/doc/home-manager/index.xhtml
|
||||||
assertFileExists home-path/share/doc/home-manager/options.html
|
assertFileExists home-path/share/doc/home-manager/options.html
|
||||||
assertFileExists home-path/share/doc/home-manager/options.json
|
assertFileExists home-path/share/doc/home-manager/options.json
|
||||||
assertFileExists home-path/share/man/man1/home-manager.1.gz
|
assertFileExists home-path/share/man/man1/home-manager.1
|
||||||
assertFileExists home-path/share/man/man5/home-configuration.nix.5.gz
|
assertFileExists home-path/share/man/man5/home-configuration.nix.5
|
||||||
'';
|
'';
|
||||||
};
|
};
|
||||||
}
|
}
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue