From fd61e87c386761d9ca9339e02966c9dcb46fa0f8 Mon Sep 17 00:00:00 2001 From: ncfavier Date: Mon, 17 Apr 2023 15:54:53 +0000 Subject: [PATCH] deploy: ae79840bc756e97f9750fc70448ae0efc1b8dcc3 --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 27d9256c..00c7ce10 100644 --- a/index.html +++ b/index.html @@ -574,7 +574,7 @@ programs.home-manager.path = "$HOME/devel/home-manager";

  • 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
+

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