From f9c612c8a17f42495f123dcda8460fada60c9b09 Mon Sep 17 00:00:00 2001 From: rycee Date: Thu, 6 May 2021 21:47:07 +0000 Subject: [PATCH] deploy: 86944b0fb15f89bc1173efabbce556260a410154 --- index.html | 6 +++--- tools.html | 14 +++++++------- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/index.html b/index.html index 12421dff9..673924146 100644 --- a/index.html +++ b/index.html @@ -1,6 +1,6 @@ -Home Manager Manual
Home Manager Manual
   Next

Home Manager Manual

Preface
1. Installing Home Manager
1.1. Standalone installation
1.2. NixOS module
1.3. nix-darwin module
2. Writing Home Manager Modules
2.1. Option Types
3. Contributing
3.1. Getting started
3.2. Guidelines
3.2.1. Maintain backward compatibility
3.2.2. Keep forward compatibility in mind
3.2.3. Add only valuable options
3.2.4. Add relevant tests
3.2.5. Add relevant documentation
3.2.6. Add yourself as a module maintainer
3.2.7. Format your code
3.2.8. Format your commit messages
3.2.9. Format your news entries
3.2.10. Use conditional modules and news
3.2.11. Mind the license
3.3. Commits
3.4. Code Style
3.5. News
3.6. Tests
4. Frequently Asked Questions (FAQ)
4.1. Why is there a collision error when switching generation?
4.2. Why are the session variables not set?
4.3. How to set up a configuration for multiple users/machines?
4.4. Why do I get an error message about ca.desrt.dconf?
4.5. How do I install packages from Nixpkgs unstable?
4.6. How do I override the package used by a module?
A. Configuration Options
B. NixOS Module Options
C. nix-darwin Module Options
D. Tools
home-manager - — reconfigure a user environment
E. Release Notes
E.1. Release 21.05
E.1.1. Highlights
E.1.2. State Version Changes
E.2. Release 20.09
E.2.1. Highlights
E.2.2. State Version Changes
E.3. Release 20.03
E.3.1. Highlights
E.3.2. State Version Changes
E.4. Release 19.09
E.4.1. Highlights
E.4.2. State Version Changes
E.5. Release 19.03
E.5.1. Highlights
E.5.2. State Version Changes
E.6. Release 18.09

Preface

+Home Manager Manual

Home Manager Manual
   Next

Home Manager Manual

Preface
1. Installing Home Manager
1.1. Standalone installation
1.2. NixOS module
1.3. nix-darwin module
2. Writing Home Manager Modules
2.1. Option Types
3. Contributing
3.1. Getting started
3.2. Guidelines
3.2.1. Maintain backward compatibility
3.2.2. Keep forward compatibility in mind
3.2.3. Add only valuable options
3.2.4. Add relevant tests
3.2.5. Add relevant documentation
3.2.6. Add yourself as a module maintainer
3.2.7. Format your code
3.2.8. Format your commit messages
3.2.9. Format your news entries
3.2.10. Use conditional modules and news
3.2.11. Mind the license
3.3. Commits
3.4. Code Style
3.5. News
3.6. Tests
4. Frequently Asked Questions (FAQ)
4.1. Why is there a collision error when switching generation?
4.2. Why are the session variables not set?
4.3. How to set up a configuration for multiple users/machines?
4.4. Why do I get an error message about ca.desrt.dconf?
4.5. How do I install packages from Nixpkgs unstable?
4.6. How do I override the package used by a module?
A. Configuration Options
B. NixOS Module Options
C. nix-darwin Module Options
D. Tools
home-manager + — reconfigure a user environment
E. Release Notes
E.1. Release 21.05
E.1.1. Highlights
E.1.2. State Version Changes
E.2. Release 20.09
E.2.1. Highlights
E.2.2. State Version Changes
E.3. Release 20.03
E.3.1. Highlights
E.3.2. State Version Changes
E.4. Release 19.09
E.4.1. Highlights
E.4.2. State Version Changes
E.5. Release 19.03
E.5.1. Highlights
E.5.2. State Version Changes
E.6. Release 18.09

Preface

This manual will eventually describes how to install, use, and extend Home Manager.

@@ -251,7 +251,7 @@ 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

3.2.6. 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.

3.2.7. Format your code

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.

3.2.8. Format your commit messages

Similar to Section 3.2.7, “Format your code” we encourage a consistent commit message format as described in Section 3.3, “Commits”.

3.2.9. 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 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.

3.2.10. 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 Section 3.5, “News” for a description of conditional news.

3.2.11. 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.

3.3. 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. 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. 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.

3.4. Code Style

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.

3.5. 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 but you should follow some basic guidelines:

  • diff --git a/tools.html b/tools.html index ed8dbffba..52f8213be 100644 --- a/tools.html +++ b/tools.html @@ -1,6 +1,6 @@ -Appendix D. Tools

    Appendix D. Tools
    Prev   Next

    Appendix D. Tools

    home-manager - — reconfigure a user environment

    Name

    home-manager +Appendix D. Tools

    Appendix D. Tools
    Prev   Next

    Appendix D. Tools

    home-manager + — reconfigure a user environment

    Name

    home-manager — reconfigure a user environment

    Synopsis

    home-manager { build | @@ -74,7 +74,7 @@ | --verbose } - ]

    Description

    + ]

    Description

    This command updates the user environment so that it corresponds to the configuration specified in ~/.config/nixpkgs/home.nix or ~/.config/nixpkgs/flake.nix.

    @@ -139,7 +139,7 @@ available for immediate garbage collection.

-

Options

+

Options

The tool accepts the options

-A attrPath @@ -234,15 +234,15 @@ --verbose

Activates verbose output. -

Files

+

Files

~/.local/share/home-manager/news-read-ids

Identifiers of news items that have been shown. Can be deleted to reset the read news indicator. -

Bugs

+

Bugs

Please report any bugs on the project issue tracker. -

See also

+

See also

home-configuration.nix(5)

Prev   Next
Appendix C. nix-darwin Module Options Home Appendix E. Release Notes
\ No newline at end of file