From c575c9e3003dc5a0d616ed8af23600be4670ee52 Mon Sep 17 00:00:00 2001 From: rycee Date: Wed, 27 Jul 2022 12:14:35 +0000 Subject: [PATCH] deploy: b13946438f235a002c6a1c966b84b124123b26cf --- index.html | 6 +++--- tools.html | 14 +++++++------- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/index.html b/index.html index 43a947ba..0f27e853 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. Using Home Manager
2.1. Configuration Example
2.2. Rollbacks
2.3. Keeping your ~ safe from harm
2.4. Graphical services
2.5. Updating
3. Nix Flakes
3.1. Prerequisties
3.2. Standalone setup
3.3. NixOS module
3.4. nix-darwin module
4. Writing Home Manager Modules
4.1. Option Types
5. Contributing
5.1. Getting started
5.2. Guidelines
5.2.1. Maintain backward compatibility
5.2.2. Keep forward compatibility in mind
5.2.3. Add only valuable options
5.2.4. Add relevant tests
5.2.5. Add relevant documentation
5.2.6. Add yourself as a module maintainer
5.2.7. Format your code
5.2.8. Format your commit messages
5.2.9. Format your news entries
5.2.10. Use conditional modules and news
5.2.11. Mind the license
5.3. Commits
5.4. Code Style
5.5. News
5.6. Tests
6. Frequently Asked Questions (FAQ)
6.1. Why is there a collision error when switching generation?
6.2. Why are the session variables not set?
6.3. How to set up a configuration for multiple users/machines?
6.4. Why do I get an error message about ca.desrt.dconf or dconf.service?
6.5. How do I install packages from Nixpkgs unstable?
6.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 22.11
E.1.1. Highlights
E.1.2. State Version Changes
E.2. Release 22.05
E.2.1. Highlights
E.2.2. State Version Changes
E.3. Release 21.11
E.3.1. Highlights
E.3.2. State Version Changes
E.4. Release 21.05
E.4.1. Highlights
E.4.2. State Version Changes
E.5. Release 20.09
E.5.1. Highlights
E.5.2. State Version Changes
E.6. Release 20.03
E.6.1. Highlights
E.6.2. State Version Changes
E.7. Release 19.09
E.7.1. Highlights
E.7.2. State Version Changes
E.8. Release 19.03
E.8.1. Highlights
E.8.2. State Version Changes
E.9. 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. Using Home Manager
2.1. Configuration Example
2.2. Rollbacks
2.3. Keeping your ~ safe from harm
2.4. Graphical services
2.5. Updating
3. Nix Flakes
3.1. Prerequisties
3.2. Standalone setup
3.3. NixOS module
3.4. nix-darwin module
4. Writing Home Manager Modules
4.1. Option Types
5. Contributing
5.1. Getting started
5.2. Guidelines
5.2.1. Maintain backward compatibility
5.2.2. Keep forward compatibility in mind
5.2.3. Add only valuable options
5.2.4. Add relevant tests
5.2.5. Add relevant documentation
5.2.6. Add yourself as a module maintainer
5.2.7. Format your code
5.2.8. Format your commit messages
5.2.9. Format your news entries
5.2.10. Use conditional modules and news
5.2.11. Mind the license
5.3. Commits
5.4. Code Style
5.5. News
5.6. Tests
6. Frequently Asked Questions (FAQ)
6.1. Why is there a collision error when switching generation?
6.2. Why are the session variables not set?
6.3. How to set up a configuration for multiple users/machines?
6.4. Why do I get an error message about ca.desrt.dconf or dconf.service?
6.5. How do I install packages from Nixpkgs unstable?
6.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 22.11
E.1.1. Highlights
E.1.2. State Version Changes
E.2. Release 22.05
E.2.1. Highlights
E.2.2. State Version Changes
E.3. Release 21.11
E.3.1. Highlights
E.3.2. State Version Changes
E.4. Release 21.05
E.4.1. Highlights
E.4.2. State Version Changes
E.5. Release 20.09
E.5.1. Highlights
E.5.2. State Version Changes
E.6. Release 20.03
E.6.1. Highlights
E.6.2. State Version Changes
E.7. Release 19.09
E.7.1. Highlights
E.7.2. State Version Changes
E.8. Release 19.03
E.8.1. Highlights
E.8.2. State Version Changes
E.9. Release 18.09

Preface

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

@@ -517,7 +517,7 @@ Does your change work for people that do not use NixOS? Consider other GNU/Linux Does your change work for people whose configuration is built on one system and deployed on another system?

5.2.2. 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 Section 5.2.3, “Add only valuable options”.

5.2.3. 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 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 Nix RFC 42.

5.2.4. 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 Section 5.6, “Tests” for more information about the Home Manager test suite.

All contributed code must pass the test suite.

5.2.5. Add relevant documentation

Many code changes require changing the documentation as well. Module options should be documented with DocBook. See DocBook rocks! for a quick introduction and DocBook 5: The Definitive Guide for in-depth information of DocBook. Home Manager is itself documented using a combination of DocBook and 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:

$ 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:

$ nix-build -A docs.manPages
-$ man ./result/share/man/man5/home-configuration.nix.5

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

5.2.7. Format your code

Make sure your code is formatted as described in Section 5.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.

5.2.8. Format your commit messages

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

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

5.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 5.5, “News” for a description of conditional news.

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

5.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}
+$ man ./result/share/man/man5/home-configuration.nix.5.gz

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

5.2.7. Format your code

Make sure your code is formatted as described in Section 5.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.

5.2.8. Format your commit messages

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

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

5.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 5.5, “News” for a description of conditional news.

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

5.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, 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 5.1, “Compliant commit message” for a commit message that fulfills these requirements.

Example 5.1. Compliant commit message

The commit 69f8e47e9e74c8d3d060ca22e18246b7f7d988ef contains the commit message

starship: allow running in Emacs if vterm is used
 
diff --git a/tools.html b/tools.html
index 853a58c4..d89bcfc1 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
      |   
@@ -84,7 +84,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.
   

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

       

-  
Options

+  
Options

    The tool accepts the options
   

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

       Activates verbose output.
-     
Files

+     
Files

      $XDG_DATA_HOME/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