diff options
Diffstat (limited to 'home-manager/doc')
| -rw-r--r-- | home-manager/doc/contributing.adoc | 255 | ||||
| -rw-r--r-- | home-manager/doc/default.nix | 10 | ||||
| -rw-r--r-- | home-manager/doc/faq.adoc | 171 | ||||
| -rw-r--r-- | home-manager/doc/installation.xml | 76 | ||||
| -rw-r--r-- | home-manager/doc/man-home-manager.xml | 14 | ||||
| -rw-r--r-- | home-manager/doc/man-pages.xml | 2 | ||||
| -rw-r--r-- | home-manager/doc/manual.xml | 14 | ||||
| -rw-r--r-- | home-manager/doc/release-notes/release-notes.adoc | 19 | ||||
| -rw-r--r-- | home-manager/doc/release-notes/release-notes.xml | 15 | ||||
| -rw-r--r-- | home-manager/doc/release-notes/rl-1903.adoc | 2 | ||||
| -rw-r--r-- | home-manager/doc/release-notes/rl-1909.adoc | 4 | ||||
| -rw-r--r-- | home-manager/doc/release-notes/rl-2003.adoc | 49 | ||||
| -rw-r--r-- | home-manager/doc/release-notes/rl-2009.adoc | 97 | ||||
| -rw-r--r-- | home-manager/doc/writing-modules.adoc | 187 |
14 files changed, 860 insertions, 55 deletions
diff --git a/home-manager/doc/contributing.adoc b/home-manager/doc/contributing.adoc new file mode 100644 index 00000000000..a6c7a3278e7 --- /dev/null +++ b/home-manager/doc/contributing.adoc @@ -0,0 +1,255 @@ +[[ch-contributing]] +== Contributing + +:open-issues: https://github.com/rycee/home-manager/issues +:new-issue: https://github.com/rycee/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/rycee/home-manager/blob/master/modules/misc/news.nix +:nixfmt: https://github.com/serokell/nixfmt/ +:example-commit-message: https://github.com/rycee/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 + +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.freenode.net/?url=irc%3A%2F%2Firc.freenode.net%2Fhome-manager +:valuable-options: https://github.com/Infinisil/rfcs/blob/config-option/rfcs/0042-config-option.md#valuable-options +:rfc-42: https://github.com/Infinisil/rfcs/blob/config-option/rfcs/0042-config-option.md + +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 never cause another user's existing configuration to break. Home Manager is used in many different environments and you should consider how you 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 +:docbook: https://tdg.docbook.org/ +:asciidoc: https://asciidoc.org/ +:docbook-rocks: https://docbook.rocks/ + +Many code changes require changing the documentation as well. Module options should be documented with DocBook. See {docbook-rocks}[DocBook rocks!] for a quick introduction and {docbook}[DocBook 5: The Definitive Guide] for in-depth information of DocBook. Home Manager is itself documented using a combination of 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 + +==== 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 NixOS 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. + +Also add yourself to `.github/CODEOWNERS` as owner of the associated module files, including the test files. You will then be automatically added as a reviewer on any new pull request that touches your files. + +Maintainers are encouraged to join the IRC 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]. 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. Note, `{description}` should start with a lower case letter. 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. + +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 diff --git a/home-manager/doc/default.nix b/home-manager/doc/default.nix index 638027b0a78..88e9756140e 100644 --- a/home-manager/doc/default.nix +++ b/home-manager/doc/default.nix @@ -1,6 +1,7 @@ -{ +{ pkgs + # Note, this should be "the standard library" + HM extensions. -lib, pkgs }: +, lib ? import ../modules/lib/stdlib-extended.nix pkgs.lib }: let @@ -8,8 +9,8 @@ let name = "nmd"; owner = "rycee"; repo = "nmd"; - rev = "b437898c2b137c39d9c5f9a1cf62ec630f14d9fc"; - sha256 = "18j1nh53cfpjpdiwn99x9kqpvr0s7hwngyc0a93xf4sg88ww93lq"; + rev = "2398aa79ab12aa7aba14bc3b08a6efd38ebabdc5"; + sha256 = "0yxb48afvccn8vvpkykzcr4q1rgv8jsijqncia7a5ffzshcrwrnh"; }; nmd = import nmdSrc { inherit lib pkgs; }; @@ -41,6 +42,7 @@ let pathName = "home-manager"; modulesDocs = [ hmModulesDocs ]; documentsDirectory = ./.; + documentType = "book"; chunkToc = '' <toc> <d:tocentry xmlns:d="http://docbook.org/ns/docbook" linkend="book-home-manager-manual"><?dbhtml filename="index.html"?> diff --git a/home-manager/doc/faq.adoc b/home-manager/doc/faq.adoc new file mode 100644 index 00000000000..b8215254dd7 --- /dev/null +++ b/home-manager/doc/faq.adoc @@ -0,0 +1,171 @@ +[[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. + +=== Why are the session variables not set? + +Home Manager is only able to set session variables automatically if it manages your Bash or Z shell configuration. 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. + +=== How do 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/nixpkgs/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`? + +You are most likely trying to configure the GTK or Gnome Terminal 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 +---- + +The solution on NixOS is to add + +[source,nix] +services.dbus.packages = with pkgs; [ gnome3.dconf ]; + +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. diff --git a/home-manager/doc/installation.xml b/home-manager/doc/installation.xml index 52119886800..3e1f75abb59 100644 --- a/home-manager/doc/installation.xml +++ b/home-manager/doc/installation.xml @@ -44,22 +44,12 @@ <orderedlist> <listitem> <para> - Make sure you have a working Nix installation. If you are not using NixOS - then it may be necessary to run - </para> -<screen> -<prompt>$</prompt> <userinput>mkdir -m 0755 -p /nix/var/nix/{profiles,gcroots}/per-user/$USER</userinput> -</screen> - <para> - since Home Manager uses these directories to manage your profile - generations. On NixOS these should already be available. - </para> - <para> - Also 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 - <literal>nix-instantiate '<nixpkgs>' -A hello</literal> 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 + 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 <literal>nix-instantiate '<nixpkgs>' -A hello</literal> + 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 <link xlink:href="https://nixos.org/nix/manual/#conf-allowed-users"><literal>allowed-users</literal></link> Nix option. On NixOS you can control this option using the <link xlink:href="https://nixos.org/nixos/manual/options.html#opt-nix.allowedUsers"><literal>nix.allowedUsers</literal></link> @@ -79,11 +69,11 @@ if you are following Nixpkgs master or an unstable channel and </para> <screen> -<prompt>$</prompt> <userinput>nix-channel --add https://github.com/rycee/home-manager/archive/release-19.09.tar.gz home-manager</userinput> +<prompt>$</prompt> <userinput>nix-channel --add https://github.com/rycee/home-manager/archive/release-20.03.tar.gz home-manager</userinput> <prompt>$</prompt> <userinput>nix-channel --update</userinput> </screen> <para> - if you follow a Nixpkgs version 19.09 channel. + if you follow a Nixpkgs version 20.03 channel. </para> <para> On NixOS you may need to log out and back in for the channel to become @@ -159,7 +149,7 @@ $HOME/.nix-profile/etc/profile.d/hm-session-vars.sh a Home Manager channel, for example </para> -<screen> +<screen language="console"> <prompt>#</prompt> <userinput>nix-channel --add https://github.com/rycee/home-manager/archive/master.tar.gz home-manager</userinput> <prompt>#</prompt> <userinput>nix-channel --update</userinput> </screen> @@ -168,13 +158,13 @@ $HOME/.nix-profile/etc/profile.d/hm-session-vars.sh if you are following Nixpkgs master or an unstable channel and </para> -<screen> -<prompt>#</prompt> <userinput>nix-channel --add https://github.com/rycee/home-manager/archive/release-19.09.tar.gz home-manager</userinput> +<screen language="console"> +<prompt>#</prompt> <userinput>nix-channel --add https://github.com/rycee/home-manager/archive/release-20.03.tar.gz home-manager</userinput> <prompt>#</prompt> <userinput>nix-channel --update</userinput> </screen> <para> - if you follow a Nixpkgs version 19.09 channel. + if you follow a Nixpkgs version 20.03 channel. </para> <para> @@ -225,6 +215,23 @@ home-manager.useUserPackages = true; become the default value in the future. </para> </note> + + <note> + <para> + By default, Home Manager uses a private <literal>pkgs</literal> instance + that is configured via the <option>home-manager.users.<name>.nixpkgs</option> options. + To instead use the global <literal>pkgs</literal> that is configured via + the system level <option>nixpkgs</option> options, set + </para> +<programlisting language="nix"> +home-manager.useGlobalPkgs = true; +</programlisting> + <para> + This saves an extra Nixpkgs evaluation, adds consistency, and removes the + dependency on <envar>NIX_PATH</envar>, which is otherwise used for + importing Nixpkgs. + </para> + </note> </section> <section xml:id="sec-install-nix-darwin-module"> <title>nix-darwin module</title> @@ -241,7 +248,7 @@ home-manager.useUserPackages = true; a Home Manager channel, for example </para> -<screen> +<screen language="console"> <prompt>#</prompt> <userinput>nix-channel --add https://github.com/rycee/home-manager/archive/master.tar.gz home-manager</userinput> <prompt>#</prompt> <userinput>nix-channel --update</userinput> </screen> @@ -250,13 +257,13 @@ home-manager.useUserPackages = true; if you are following Nixpkgs master or an unstable channel and </para> -<screen> -<prompt>#</prompt> <userinput>nix-channel --add https://github.com/rycee/home-manager/archive/release-19.09.tar.gz home-manager</userinput> +<screen language="console"> +<prompt>#</prompt> <userinput>nix-channel --add https://github.com/rycee/home-manager/archive/release-20.03.tar.gz home-manager</userinput> <prompt>#</prompt> <userinput>nix-channel --update</userinput> </screen> <para> - if you follow a Nixpkgs version 19.09 channel. + if you follow a Nixpkgs version 20.03 channel. </para> <para> @@ -306,5 +313,22 @@ home-manager.useUserPackages = true; value in the future. </para> </note> + + <note> + <para> + By default, Home Manager uses a private <literal>pkgs</literal> instance + that is configured via the <option>home-manager.users.<name>.nixpkgs</option> options. + To instead use the global <literal>pkgs</literal> that is configured via + the system level <option>nixpkgs</option> options, set + </para> +<programlisting language="nix"> +home-manager.useGlobalPkgs = true; +</programlisting> + <para> + This saves an extra Nixpkgs evaluation, adds consistency, and removes the + dependency on <envar>NIX_PATH</envar>, which is otherwise used for + importing Nixpkgs. + </para> + </note> </section> </chapter> diff --git a/home-manager/doc/man-home-manager.xml b/home-manager/doc/man-home-manager.xml index 117bc494687..90f58063ea9 100644 --- a/home-manager/doc/man-home-manager.xml +++ b/home-manager/doc/man-home-manager.xml @@ -18,6 +18,10 @@ </arg> <arg choice="plain"> + instantiate + </arg> + + <arg choice="plain"> edit </arg> @@ -165,6 +169,16 @@ </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> diff --git a/home-manager/doc/man-pages.xml b/home-manager/doc/man-pages.xml index 616c2ef291b..bb484ae019b 100644 --- a/home-manager/doc/man-pages.xml +++ b/home-manager/doc/man-pages.xml @@ -4,7 +4,7 @@ <title>Home Manager Reference Pages</title> <info> <author><personname>Home Manager contributors</personname></author> - <copyright><year>2017–2019</year><holder>Home Manager contributors</holder> + <copyright><year>2017–2020</year><holder>Home Manager contributors</holder> </copyright> </info> <xi:include href="man-configuration.xml" /> diff --git a/home-manager/doc/manual.xml b/home-manager/doc/manual.xml index 8ff81308b2c..ff355d6ce1e 100644 --- a/home-manager/doc/manual.xml +++ b/home-manager/doc/manual.xml @@ -13,9 +13,14 @@ Manager. </para> <para> - If you encounter problems or bugs then please report them on the - <link xlink:href="https://github.com/rycee/home-manager/issues">Home Manager - issue tracker</link>. + If you encounter problems then please reach out on the IRC channel + <link xlink:href="https://webchat.freenode.net/?url=irc%3A%2F%2Firc.freenode.net%2Fhome-manager">#home-manager</link> + hosted by <link xlink:href="https://freenode.net/">freenode</link>. + The <link xlink:href="https://logs.nix.samueldr.com/home-manager/">channel logs</link> + are hosted courtesy of <link xlink:href="https://github.com/samueldr/">samueldr</link>. + If your problem is caused by a bug in Home Manager then it should + be reported on the + <link xlink:href="https://github.com/rycee/home-manager/issues">Home Manager issue tracker</link>. </para> <note> <para> @@ -26,6 +31,9 @@ </note> </preface> <xi:include href="installation.xml" /> + <xi:include href="writing-modules.xml" /> + <xi:include href="contributing.xml" /> + <xi:include href="faq.xml" /> <appendix xml:id="ch-options"> <title>Configuration Options</title> <xi:include href="./nmd-result/home-manager-options.xml" /> diff --git a/home-manager/doc/release-notes/release-notes.adoc b/home-manager/doc/release-notes/release-notes.adoc new file mode 100644 index 00000000000..9a98e3850c3 --- /dev/null +++ b/home-manager/doc/release-notes/release-notes.adoc @@ -0,0 +1,19 @@ +[[ch-release-notes]] +[appendix] +== Release Notes + +This section lists the release notes for stable versions of Home Manager and the current unstable version. + +:leveloffset: 1 + +include::rl-2009.adoc[] + +include::rl-2003.adoc[] + +include::rl-1909.adoc[] + +include::rl-1903.adoc[] + +include::rl-1809.adoc[] + +:leveloffset: 0 diff --git a/home-manager/doc/release-notes/release-notes.xml b/home-manager/doc/release-notes/release-notes.xml deleted file mode 100644 index 2c1f5fcde3b..00000000000 --- a/home-manager/doc/release-notes/release-notes.xml +++ /dev/null @@ -1,15 +0,0 @@ -<appendix 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="ch-release-notes"> - <title>Release Notes</title> - <para> - This section lists the release notes for stable versions of Home Manager and - the current unstable version. - </para> - <xi:include href="rl-2003.xml" /> - <xi:include href="rl-1909.xml" /> - <xi:include href="rl-1903.xml" /> - <xi:include href="rl-1809.xml" /> -</appendix> diff --git a/home-manager/doc/release-notes/rl-1903.adoc b/home-manager/doc/release-notes/rl-1903.adoc index 6dfdc67f5bf..1cba4235d60 100644 --- a/home-manager/doc/release-notes/rl-1903.adoc +++ b/home-manager/doc/release-notes/rl-1903.adoc @@ -5,7 +5,7 @@ The 19.03 release branch became the stable branch in April, 2019. [[sec-release-19.03-highlights]] === Highlights -:opt-home-file-source: opt-home.file._name__.source +:opt-home-file-source: opt-home.file._name_.source This release has the following notable changes: diff --git a/home-manager/doc/release-notes/rl-1909.adoc b/home-manager/doc/release-notes/rl-1909.adoc index 2cc90c164de..89bbbdc2b4f 100644 --- a/home-manager/doc/release-notes/rl-1909.adoc +++ b/home-manager/doc/release-notes/rl-1909.adoc @@ -8,8 +8,8 @@ The 19.09 release branch became the stable branch in October, 2019. This release has the following notable changes: -* The <<opt-programs.firefox.enableGoogleTalk>> and - <<opt-programs.firefox.enableIcedTea>> options are now deprecated +* The `programs.firefox.enableGoogleTalk` and + `programs.firefox.enableIcedTea` options are now deprecated and will only work if Firefox ESR 52.x is used. * The `home-manager` tool now provides an `uninstall` sub-command that diff --git a/home-manager/doc/release-notes/rl-2003.adoc b/home-manager/doc/release-notes/rl-2003.adoc index fc1dcd7cfe2..5832e2e5ab5 100644 --- a/home-manager/doc/release-notes/rl-2003.adoc +++ b/home-manager/doc/release-notes/rl-2003.adoc @@ -1,8 +1,7 @@ [[sec-release-20.03]] -== Release 20.03 (unreleased) +== Release 20.03 -This is the current unstable branch and the information in this -section is therefore not final. +The 20.03 release branch became the stable branch in April, 2020. [[sec-release-20.03-highlights]] === Highlights @@ -69,6 +68,47 @@ use home-manager.users.jane = { config.config = "foo"; }; ---- +* The `services.compton` module has been deprecated and instead the +new module `services.picom` should be used. This is because Nixpkgs no +longer packages compton, and instead packages the (mostly) compatible +fork called picom. + +* The list form of the <<opt-programs.ssh.matchBlocks>> option has +been deprecated and configurations requiring match blocks in a defined +order should switch to using DAG entries instead. For example, a +configuration ++ +[source,nix] +---- +programs.ssh.matchBlocks = [ + { + host = "alpha.foo.com"; + user = "jd"; + } + { + host = "*.foo.com"; + user = "john.doe"; + } +]; +---- ++ +can be expressed along the lines of ++ +[source,nix] +---- +programs.ssh.matchBlocks = { + "*.example.com" = { + user = "john.doe"; + } + "alpha.example.com" = lib.hm.dag.entryBefore ["*.example.com"] { + user = "jd"; + } +}; +---- ++ +Support for the list form will be removed in Home Manager version +20.09. + [[sec-release-20.03-state-version-changes]] === State Version Changes @@ -81,3 +121,6 @@ changes are only active if the `home.stateVersion` option is set to using the xdg module. Also, the default value is fixed to `$HOME/.zsh_history` and `dotDir` path is not prepended to it anymore. +* The newsboat module will now default in displaying `queries` before `urls` in + its main window. This makes sense in the case when one has a lot of URLs and + few queries. diff --git a/home-manager/doc/release-notes/rl-2009.adoc b/home-manager/doc/release-notes/rl-2009.adoc new file mode 100644 index 00000000000..c1939ab5af9 --- /dev/null +++ b/home-manager/doc/release-notes/rl-2009.adoc @@ -0,0 +1,97 @@ +[[sec-release-20.09]] +== Release 20.09 (unreleased) + +This is the current unstable branch and the information in this +section is therefore not final. + +[[sec-release-20.09-highlights]] +=== Highlights + +This release has the following notable changes: + +* Nothing has happened. + +[[sec-release-20.09-state-version-changes]] +=== State Version Changes + +The state version in this release includes the changes below. These +changes are only active if the `home.stateVersion` option is set to +"20.09" or later. + +* The options <<opt-home.homeDirectory>> and <<opt-home.username>> no +longer have default values and must therefore be provided in your +configuration. Previously their values would default to the content of +the environment variables `HOME` and `USER`, respectively. ++ +-- +Further, the options <<opt-xdg.cacheHome>>, <<opt-xdg.configHome>>, +and <<opt-xdg.dataHome>> will no longer be affected by the +`XDG_CACHE_HOME`, `XDG_CONFIG_HOME`, and `XDG_DATA_HOME` environment +variables. They now unconditionally default to + +- `"${config.home.homeDirectory}/.cache"`, +- `"${config.home.homeDirectory}/.config"`, and +- `"${config.home.homeDirectory}/.local/share"`. + +If you choose to switch to state version 20.09 then you must set these +options if you use non-default XDG base directory paths. + +The initial configuration generated by + +[source,console] +$ nix-shell '<home-manager>' -A install + +will automatically include these options, when necessary. +-- + +* Git's `smtpEncryption` option is now set to `tls` only if both <<opt-accounts.email.accounts.\_name_.smtp.tls.enable>> and <<opt-accounts.email.accounts.\_name_.smtp.tls.useStartTls>> are `true`. If only <<opt-accounts.email.accounts.\_name_.smtp.tls.enable>> is `true`, `ssl` is used instead. + +* The `nixpkgs` module no longer references `<nixpkgs>`. Before it would do so when building the `pkgs` module argument. Starting with state version 20.09, the `pkgs` argument is instead built from the same Nixpkgs that was used to initialize the Home Manager modules. This is useful, for example, when using Home Manager within a Nix Flake. If you want to keep using `<nixpkgs>` with state version ≥ 20.09 then add ++ +[source,nix] +_module.args.pkgsPath = <nixpkgs>; ++ +to your Home Manager configuration. + +* The options `wayland.windowManager.sway.config.bars` and `opt-xsession.windowManager.i3.config.bars` have been changed so that most of the suboptions are now nullable and default to `null`. The default for these two options has been changed to manually set the old defaults for each suboption. The overall effect is that if the `bars` options is not set, then the default remains the same. On the other hand, something like: ++ +-- +[source,nix] +---- +bars = [ { + command = "waybar"; +} ]; +---- +will now create the config: +.... +bar { + swaybar_command waybar +} +.... +instead of +.... +bar { + + font pango:monospace 8 + mode dock + hidden_state hide + position bottom + status_command /nix/store/h7s6i9q1z5fxrlyyw5ls8vqxhf5bcs5a-i3status-2.13/bin/i3status + swaybar_command waybar + workspace_buttons yes + strip_workspace_numbers no + tray_output primary + colors { + background #000000 + statusline #ffffff + separator #666666 + focused_workspace #4c7899 #285577 #ffffff + active_workspace #333333 #5f676a #ffffff + inactive_workspace #333333 #222222 #888888 + urgent_workspace #2f343a #900000 #ffffff + binding_mode #2f343a #900000 #ffffff + } + +} +.... +-- diff --git a/home-manager/doc/writing-modules.adoc b/home-manager/doc/writing-modules.adoc new file mode 100644 index 00000000000..0f3336ff2c0 --- /dev/null +++ b/home-manager/doc/writing-modules.adoc @@ -0,0 +1,187 @@ +[[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://developer.gnome.org/glib/stable/glib-GVariant.html#glib-GVariant.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>>. + +`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`. ++ +`hm.dag.entryAnywhere (value: 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. ++ +`hm.dag.entryAfter (afters: list string) (value: 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. ++ +`hm.dag.entryBefore (befores: list string) (value: 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. ++ +`hm.dag.entryBetween (befores: list string) (afters: list string) (value: 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. + +`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 and tuples. Dictionaries are not currently supported. ++ +To create a GVariant value you can use a number of provided functions. Examples assume an option `foo.bar` of type `hm.types.gvariant`. ++ +`hm.gvariant.mkBoolean (v: bool)`::: +Takes a Nix value `v` to a GVariant `boolean` value. 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; +---- +`hm.gvariant.mkString (v: string)`::: +Takes a Nix value `v` to a GVariant `string` value. 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"; +---- +`hm.gvariant.mkObjectpath (v: string)`::: +Takes a Nix value `v` to a GVariant `objectpath` value. +`hm.gvariant.mkUchar (v: string)`::: +Takes a Nix value `v` to a GVariant `uchar` value. +`hm.gvariant.mkInt16 (v: int)`::: +Takes a Nix value `v` to a GVariant `int16` value. +`hm.gvariant.mkUint16 (v: int)`::: +Takes a Nix value `v` to a GVariant `uint16` value. +`hm.gvariant.mkInt32 (v: int)`::: +Takes a Nix value `v` to a GVariant `int32` value. 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; +---- +`hm.gvariant.mkUint32 (v: int)`::: +Takes a Nix value `v` to a GVariant `uint32` value. +`hm.gvariant.mkInt64 (v: int)`::: +Takes a Nix value `v` to a GVariant `int64` value. +`hm.gvariant.mkUint64 (v: int)`::: +Takes a Nix value `v` to a GVariant `uint64` value. +`hm.gvariant.mkDouble (v: double)`::: +Takes a Nix value `v` to a GVariant `double` value. 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; +---- ++ +`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. The `type` value can be constructed using ++ +-- +- `hm.gvariant.type.string` +- `hm.gvariant.type.boolean` +- `hm.gvariant.type.uchar` +- `hm.gvariant.type.int16` +- `hm.gvariant.type.uint16` +- `hm.gvariant.type.int32` +- `hm.gvariant.type.uint32` +- `hm.gvariant.type.int64` +- `hm.gvariant.type.uint64` +- `hm.gvariant.type.double` +- `hm.gvariant.type.arrayOf type` +- `hm.gvariant.type.maybeOf type` +- `hm.gvariant.type.tupleOf types` +-- ++ +where `type` and `types` are themselves a type and list of types, respectively. ++ +`hm.gvariant.mkEmptyArray type`::: +An alias of `hm.gvariant.mkArray type []`. ++ +`hm.gvariant.mkNothing type`::: +Builds a GVariant maybe value whose (non-existent) element is of the given type. The `type` value is constructed as described for the `mkArray` function above. ++ +`hm.gvariant.mkJust element`::: +Builds a GVariant maybe value containing the given GVariant element. ++ +`hm.gvariant.mkTuple elements`::: +Builds a GVariant tuple containing the given list of elements, where each element is a GVariant value. |