ca.desrt.dconf?+
ca.desrt.dconf?This manual will eventually describes how to install, use, and extend Home Manager.
@@ -11,7 +11,7 @@ are hosted courtesy of samueldr. If your problem is caused by a bug in Home Manager then it should be reported on the - Home Manager issue tracker. + Home Manager issue tracker.
Commands prefixed with # have to be run as root, either
requiring to login as root user or temporarily switching to it using
@@ -54,12 +54,12 @@
Add the Home Manager channel that you wish to follow. This is done by
running
-$nix-channel --add https://github.com/rycee/home-manager/archive/master.tar.gz home-manager+$nix-channel --add https://github.com/nix-community/home-manager/archive/master.tar.gz home-manager$nix-channel --update
if you are following Nixpkgs master or an unstable channel and
-$nix-channel --add https://github.com/rycee/home-manager/archive/release-20.03.tar.gz home-manager+$nix-channel --add https://github.com/nix-community/home-manager/archive/release-20.03.tar.gz home-manager$nix-channel --update
if you follow a Nixpkgs version 20.03 channel. @@ -112,12 +112,12 @@ $HOME/.nix-profile/etc/profile.d/hm-session-vars.sh it into your system configuration. This is most conveniently done by adding a Home Manager channel, for example
-#nix-channel --add https://github.com/rycee/home-manager/archive/master.tar.gz home-manager+#nix-channel --add https://github.com/nix-community/home-manager/archive/master.tar.gz home-manager#nix-channel --update
if you are following Nixpkgs master or an unstable channel and
-#nix-channel --add https://github.com/rycee/home-manager/archive/release-20.03.tar.gz home-manager+#nix-channel --add https://github.com/nix-community/home-manager/archive/release-20.03.tar.gz home-manager#nix-channel --update
if you follow a Nixpkgs version 20.03 channel. @@ -172,12 +172,12 @@ home-manager.useGlobalPkgs = true; it into your system configuration. This is most conveniently done by adding a Home Manager channel, for example
-#nix-channel --add https://github.com/rycee/home-manager/archive/master.tar.gz home-manager+#nix-channel --add https://github.com/nix-community/home-manager/archive/master.tar.gz home-manager#nix-channel --update
if you are following Nixpkgs master or an unstable channel and
-#nix-channel --add https://github.com/rycee/home-manager/archive/release-20.03.tar.gz home-manager+#nix-channel --add https://github.com/nix-community/home-manager/archive/release-20.03.tar.gz home-manager#nix-channel --update
if you follow a Nixpkgs version 20.03 channel.
@@ -348,7 +348,7 @@ Builds a GVariant maybe value containing the given GVariant element.
hm.gvariant.mkTuple elements
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 Section 3.1, “Getting started” for information on how to set up a suitable development environment and Section 3.2, “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, 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 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.
If you have not previously forked Home Manager then you need to do that first. Have a look at GitHub’s 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 Section 3.2, “Guidelines” then push the branch to GitHub and 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
+
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 Section 3.1, “Getting started” for information on how to set up a suitable development environment and Section 3.2, “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, 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 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.
If you have not previously forked Home Manager then you need to do that first. Have a look at GitHub’s 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 Section 3.2, “Guidelines” then push the branch to GitHub and 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
overriding the default path by using the -I command line option:
$ home-manager -I home-manager=$HOME/devel/home-manager
or
changing the default path by ensuring your configuration includes @@ -361,10 +361,10 @@ Does your change work for people whose configuration is built on one system and $ 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:
$ nix-build -A docs.manPages $ man ./result/share/man/man5/home-configuration.nix.5
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.
Make sure your code is formatted as described in Section 3.4, “Code Style”. To maintain consistency throughout the project you are encouraged to browse through existing code and adopt its style also in new code.
Similar to Section 3.2.7, “Format your code” we encourage a consistent commit message format as described in Section 3.3, “Commits”.
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 Section 3.5, “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.
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 Section 3.5, “News” for a description of conditional news.
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.
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. 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 Example 3.1, “Compliant commit message” for a commit message that fulfills these requirements.
Example 3.1. Compliant commit message
The commit 69f8e47e9e74c8d3d060ca22e18246b7f7d988ef contains the commit message
starship: allow running in Emacs if vterm is used
+{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 Example 3.1, “Compliant commit message” for a commit message that fulfills these requirements.
Example 3.1. Compliant commit message
The 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.
The code in Home Manager is formatted by the 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.
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 but you should follow some basic guidelines:
+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.
The code in Home Manager is formatted by the 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.
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 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
$ date --iso-8601=second --universal
Declared by:
+ Declared by: accounts.email.accounts.<name>.addressThe email address of this account. Type: string matching the pattern .*@.* Example: Declared by:
|