diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/functions.xml | 741 | ||||
| -rw-r--r-- | doc/manual.xml | 1 | ||||
| -rw-r--r-- | doc/reviewing-contributions.xml | 393 |
3 files changed, 786 insertions, 349 deletions
diff --git a/doc/functions.xml b/doc/functions.xml index 3850e58c0168..70326936a570 100644 --- a/doc/functions.xml +++ b/doc/functions.xml @@ -8,252 +8,295 @@ The nixpkgs repository has several utility functions to manipulate Nix expressions. </para> -<section xml:id="sec-pkgs-overridePackages"> - <title>pkgs.overridePackages</title> +<section xml:id="sec-overrides"> + <title>Overriding</title> <para> - This function inside the nixpkgs expression (<varname>pkgs</varname>) - can be used to override the set of packages itself. - </para> - <para> - Warning: this function is expensive and must not be used from within - the nixpkgs repository. - </para> - <para> - Example usage: - - <programlisting>let - pkgs = import <nixpkgs> {}; - newpkgs = pkgs.overridePackages (self: super: { - foo = super.foo.override { ... }; - }; -in ...</programlisting> + Sometimes one wants to override parts of + <literal>nixpkgs</literal>, e.g. derivation attributes, the results of + derivations or even the whole package set. </para> - <para> - The resulting <varname>newpkgs</varname> will have the new <varname>foo</varname> - expression, and all other expressions depending on <varname>foo</varname> will also - use the new <varname>foo</varname> expression. - </para> + <section xml:id="sec-pkgs-overridePackages"> + <title>pkgs.overridePackages</title> - <para> - The behavior of this function is similar to <link - linkend="sec-modify-via-packageOverrides">config.packageOverrides</link>. - </para> + <para> + This function inside the nixpkgs expression (<varname>pkgs</varname>) + can be used to override the set of packages itself. + </para> + <para> + Warning: this function is expensive and must not be used from within + the nixpkgs repository. + </para> + <para> + Example usage: - <para> - The <varname>self</varname> parameter refers to the final package set with the - applied overrides. Using this parameter may lead to infinite recursion if not - used consciously. - </para> + <programlisting>let + pkgs = import <nixpkgs> {}; + newpkgs = pkgs.overridePackages (self: super: { + foo = super.foo.override { ... }; + }; + in ...</programlisting> + </para> - <para> - The <varname>super</varname> parameter refers to the old package set. - It's equivalent to <varname>pkgs</varname> in the above example. - </para> + <para> + The resulting <varname>newpkgs</varname> will have the new <varname>foo</varname> + expression, and all other expressions depending on <varname>foo</varname> will also + use the new <varname>foo</varname> expression. + </para> - <para> - Note that in previous versions of nixpkgs, this method replaced any changes from <link - linkend="sec-modify-via-packageOverrides">config.packageOverrides</link>, - along with that from previous calls if this function was called repeatedly. - Now those previous changes will be preserved so this function can be "chained" meaningfully. - To recover the old behavior, make sure <varname>config.packageOverrides</varname> is unset, - and call this only once off a "freshly" imported nixpkgs: - - <programlisting>let - pkgs = import <nixpkgs> { config: {}; }; - newpkgs = pkgs.overridePackages ...; -in ...</programlisting> - </para> + <para> + The behavior of this function is similar to <link + linkend="sec-modify-via-packageOverrides">config.packageOverrides</link>. + </para> -</section> + <para> + The <varname>self</varname> parameter refers to the final package set with the + applied overrides. Using this parameter may lead to infinite recursion if not + used consciously. + </para> -<section xml:id="sec-pkg-override"> - <title><pkg>.override</title> + <para> + The <varname>super</varname> parameter refers to the old package set. + It's equivalent to <varname>pkgs</varname> in the above example. + </para> - <para> - The function <varname>override</varname> is usually available for all the - derivations in the nixpkgs expression (<varname>pkgs</varname>). - </para> - <para> - It is used to override the arguments passed to a function. - </para> - <para> - Example usages: - - <programlisting>pkgs.foo.override { arg1 = val1; arg2 = val2; ... }</programlisting> - <programlisting>pkgs.overridePackages (self: super: { - foo = super.foo.override { barSupport = true ; }; -})</programlisting> - <programlisting>mypkg = pkgs.callPackage ./mypkg.nix { - mydep = pkgs.mydep.override { ... }; -})</programlisting> - </para> + <para> + Note that in previous versions of nixpkgs, this method replaced any changes from <link + linkend="sec-modify-via-packageOverrides">config.packageOverrides</link>, + along with that from previous calls if this function was called repeatedly. + Now those previous changes will be preserved so this function can be "chained" meaningfully. + To recover the old behavior, make sure <varname>config.packageOverrides</varname> is unset, + and call this only once off a "freshly" imported nixpkgs: + + <programlisting>let + pkgs = import <nixpkgs> { config: {}; }; + newpkgs = pkgs.overridePackages ...; + in ...</programlisting> + </para> - <para> - In the first example, <varname>pkgs.foo</varname> is the result of a function call - with some default arguments, usually a derivation. - Using <varname>pkgs.foo.override</varname> will call the same function with - the given new arguments. - </para> + </section> -</section> + <section xml:id="sec-pkg-override"> + <title><pkg>.override</title> -<section xml:id="sec-pkg-overrideAttrs"> - <title><pkg>.overrideAttrs</title> + <para> + The function <varname>override</varname> is usually available for all the + derivations in the nixpkgs expression (<varname>pkgs</varname>). + </para> + <para> + It is used to override the arguments passed to a function. + </para> + <para> + Example usages: + + <programlisting>pkgs.foo.override { arg1 = val1; arg2 = val2; ... }</programlisting> + <programlisting>pkgs.overridePackages (self: super: { + foo = super.foo.override { barSupport = true ; }; + })</programlisting> + <programlisting>mypkg = pkgs.callPackage ./mypkg.nix { + mydep = pkgs.mydep.override { ... }; + })</programlisting> + </para> - <para> - The function <varname>overrideAttrs</varname> allows overriding the - attribute set passed to a <varname>stdenv.mkDerivation</varname> call, - producing a new derivation based on the original one. - This function is available on all derivations produced by the - <varname>stdenv.mkDerivation</varname> function, which is most packages - in the nixpkgs expression <varname>pkgs</varname>. - </para> + <para> + In the first example, <varname>pkgs.foo</varname> is the result of a function call + with some default arguments, usually a derivation. + Using <varname>pkgs.foo.override</varname> will call the same function with + the given new arguments. + </para> - <para> - Example usage: + </section> - <programlisting>helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec { - separateDebugInfo = true; -});</programlisting> - </para> + <section xml:id="sec-pkg-overrideAttrs"> + <title><pkg>.overrideAttrs</title> - <para> - In the above example, the <varname>separateDebugInfo</varname> attribute is - overriden to be true, thus building debug info for - <varname>helloWithDebug</varname>, while all other attributes will be - retained from the original <varname>hello</varname> package. - </para> + <para> + The function <varname>overrideAttrs</varname> allows overriding the + attribute set passed to a <varname>stdenv.mkDerivation</varname> call, + producing a new derivation based on the original one. + This function is available on all derivations produced by the + <varname>stdenv.mkDerivation</varname> function, which is most packages + in the nixpkgs expression <varname>pkgs</varname>. + </para> - <para> - The argument <varname>oldAttrs</varname> is conventionally used to refer to - the attr set originally passed to <varname>stdenv.mkDerivation</varname>. - </para> + <para> + Example usage: + + <programlisting>helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec { + separateDebugInfo = true; + });</programlisting> + </para> - <note> <para> - Note that <varname>separateDebugInfo</varname> is processed only by the - <varname>stdenv.mkDerivation</varname> function, not the generated, raw - Nix derivation. Thus, using <varname>overrideDerivation</varname> will - not work in this case, as it overrides only the attributes of the final - derivation. It is for this reason that <varname>overrideAttrs</varname> - should be preferred in (almost) all cases to - <varname>overrideDerivation</varname>, i.e. to allow using - <varname>sdenv.mkDerivation</varname> to process input arguments, as well - as the fact that it is easier to use (you can use the same attribute - names you see in your Nix code, instead of the ones generated (e.g. - <varname>buildInputs</varname> vs <varname>nativeBuildInputs</varname>, - and involves less typing. + In the above example, the <varname>separateDebugInfo</varname> attribute is + overriden to be true, thus building debug info for + <varname>helloWithDebug</varname>, while all other attributes will be + retained from the original <varname>hello</varname> package. </para> - </note> -</section> + <para> + The argument <varname>oldAttrs</varname> is conventionally used to refer to + the attr set originally passed to <varname>stdenv.mkDerivation</varname>. + </para> + + <note> + <para> + Note that <varname>separateDebugInfo</varname> is processed only by the + <varname>stdenv.mkDerivation</varname> function, not the generated, raw + Nix derivation. Thus, using <varname>overrideDerivation</varname> will + not work in this case, as it overrides only the attributes of the final + derivation. It is for this reason that <varname>overrideAttrs</varname> + should be preferred in (almost) all cases to + <varname>overrideDerivation</varname>, i.e. to allow using + <varname>sdenv.mkDerivation</varname> to process input arguments, as well + as the fact that it is easier to use (you can use the same attribute + names you see in your Nix code, instead of the ones generated (e.g. + <varname>buildInputs</varname> vs <varname>nativeBuildInputs</varname>, + and involves less typing. + </para> + </note> + + </section> -<section xml:id="sec-pkg-overrideDerivation"> - <title><pkg>.overrideDerivation</title> + <section xml:id="sec-pkg-overrideDerivation"> + <title><pkg>.overrideDerivation</title> - <warning> - <para>You should prefer <varname>overrideAttrs</varname> in almost all - cases, see its documentation for the reasons why. - <varname>overrideDerivation</varname> is not deprecated and will continue - to work, but is less nice to use and does not have as many abilities as - <varname>overrideAttrs</varname>. + <warning> + <para>You should prefer <varname>overrideAttrs</varname> in almost all + cases, see its documentation for the reasons why. + <varname>overrideDerivation</varname> is not deprecated and will continue + to work, but is less nice to use and does not have as many abilities as + <varname>overrideAttrs</varname>. + </para> + </warning> + + <warning> + <para>Do not use this function in Nixpkgs as it evaluates a Derivation + before modifying it, which breaks package abstraction and removes + error-checking of function arguments. In addition, this + evaluation-per-function application incurs a performance penalty, + which can become a problem if many overrides are used. + It is only intended for ad-hoc customisation, such as in + <filename>~/.nixpkgs/config.nix</filename>. </para> - </warning> + </warning> - <warning> - <para>Do not use this function in Nixpkgs as it evaluates a Derivation - before modifying it, which breaks package abstraction and removes - error-checking of function arguments. In addition, this - evaluation-per-function application incurs a performance penalty, - which can become a problem if many overrides are used. - It is only intended for ad-hoc customisation, such as in - <filename>~/.nixpkgs/config.nix</filename>. - </para> - </warning> + <para> + The function <varname>overrideDerivation</varname> creates a new derivation + based on an existing one by overriding the original's attributes with + the attribute set produced by the specified function. + This function is available on all + derivations defined using the <varname>makeOverridable</varname> function. + Most standard derivation-producing functions, such as + <varname>stdenv.mkDerivation</varname>, are defined using this + function, which means most packages in the nixpkgs expression, + <varname>pkgs</varname>, have this function. + </para> - <para> - The function <varname>overrideDerivation</varname> creates a new derivation - based on an existing one by overriding the original's attributes with - the attribute set produced by the specified function. - This function is available on all - derivations defined using the <varname>makeOverridable</varname> function. - Most standard derivation-producing functions, such as - <varname>stdenv.mkDerivation</varname>, are defined using this - function, which means most packages in the nixpkgs expression, - <varname>pkgs</varname>, have this function. - </para> + <para> + Example usage: - <para> - Example usage: - - <programlisting>mySed = pkgs.gnused.overrideDerivation (oldAttrs: { - name = "sed-4.2.2-pre"; - src = fetchurl { - url = ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2; - sha256 = "11nq06d131y4wmf3drm0yk502d2xc6n5qy82cg88rb9nqd2lj41k"; - }; - patches = []; -});</programlisting> - </para> + <programlisting>mySed = pkgs.gnused.overrideDerivation (oldAttrs: { + name = "sed-4.2.2-pre"; + src = fetchurl { + url = ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2; + sha256 = "11nq06d131y4wmf3drm0yk502d2xc6n5qy82cg88rb9nqd2lj41k"; + }; + patches = []; + });</programlisting> + </para> - <para> - In the above example, the <varname>name</varname>, <varname>src</varname>, - and <varname>patches</varname> of the derivation will be overridden, while - all other attributes will be retained from the original derivation. - </para> + <para> + In the above example, the <varname>name</varname>, <varname>src</varname>, + and <varname>patches</varname> of the derivation will be overridden, while + all other attributes will be retained from the original derivation. + </para> - <para> - The argument <varname>oldAttrs</varname> is used to refer to the attribute set of - the original derivation. - </para> + <para> + The argument <varname>oldAttrs</varname> is used to refer to the attribute set of + the original derivation. + </para> + + <note> + <para> + A package's attributes are evaluated *before* being modified by + the <varname>overrideDerivation</varname> function. + For example, the <varname>name</varname> attribute reference + in <varname>url = "mirror://gnu/hello/${name}.tar.gz";</varname> + is filled-in *before* the <varname>overrideDerivation</varname> function + modifies the attribute set. This means that overriding the + <varname>name</varname> attribute, in this example, *will not* change the + value of the <varname>url</varname> attribute. Instead, we need to override + both the <varname>name</varname> *and* <varname>url</varname> attributes. + </para> + </note> + + </section> + + <section xml:id="sec-lib-makeOverridable"> + <title>lib.makeOverridable</title> - <note> <para> - A package's attributes are evaluated *before* being modified by - the <varname>overrideDerivation</varname> function. - For example, the <varname>name</varname> attribute reference - in <varname>url = "mirror://gnu/hello/${name}.tar.gz";</varname> - is filled-in *before* the <varname>overrideDerivation</varname> function - modifies the attribute set. This means that overriding the - <varname>name</varname> attribute, in this example, *will not* change the - value of the <varname>url</varname> attribute. Instead, we need to override - both the <varname>name</varname> *and* <varname>url</varname> attributes. + The function <varname>lib.makeOverridable</varname> is used to make the result + of a function easily customizable. This utility only makes sense for functions + that accept an argument set and return an attribute set. </para> - </note> -</section> + <para> + Example usage: -<section xml:id="sec-lib-makeOverridable"> - <title>lib.makeOverridable</title> + <programlisting>f = { a, b }: { result = a+b; } + c = lib.makeOverridable f { a = 1; b = 2; }</programlisting> - <para> - The function <varname>lib.makeOverridable</varname> is used to make the result - of a function easily customizable. This utility only makes sense for functions - that accept an argument set and return an attribute set. - </para> + </para> - <para> - Example usage: + <para> + The variable <varname>c</varname> is the value of the <varname>f</varname> function + applied with some default arguments. Hence the value of <varname>c.result</varname> + is <literal>3</literal>, in this example. + </para> - <programlisting>f = { a, b }: { result = a+b; } -c = lib.makeOverridable f { a = 1; b = 2; }</programlisting> + <para> + The variable <varname>c</varname> however also has some additional functions, like + <link linkend="sec-pkg-override">c.override</link> which can be used to + override the default arguments. In this example the value of + <varname>(c.override { a = 4; }).result</varname> is 6. + </para> + + </section> + +</section> +<section xml:id="sec-generators"> + <title>Generators</title> + + <para> + Generators are functions that create file formats from nix + data structures, e. g. for configuration files. + There are generators available for: <literal>INI</literal>, + <literal>JSON</literal> and <literal>YAML</literal> </para> <para> - The variable <varname>c</varname> is the value of the <varname>f</varname> function - applied with some default arguments. Hence the value of <varname>c.result</varname> - is <literal>3</literal>, in this example. + All generators follow a similar call interface: <code>generatorName + configFunctions data</code>, where <literal>configFunctions</literal> is a + set of user-defined functions that format variable parts of the content. + They each have common defaults, so often they do not need to be set + manually. An example is <code>mkSectionName ? (name: libStr.escape [ "[" "]" + ] name)</code> from the <literal>INI</literal> generator. It gets the name + of a section and returns a sanitized name. The default + <literal>mkSectionName</literal> escapes <literal>[</literal> and + <literal>]</literal> with a backslash. </para> + <note><para>Nix store paths can be converted to strings by enclosing a + derivation attribute like so: <code>"${drv}"</code>.</para></note> + <para> - The variable <varname>c</varname> however also has some additional functions, like - <link linkend="sec-pkg-override">c.override</link> which can be used to - override the default arguments. In this example the value of - <varname>(c.override { a = 4; }).result</varname> is 6. + Detailed documentation for each generator can be found in + <literal>lib/generators.nix</literal>. </para> </section> @@ -370,37 +413,37 @@ c = lib.makeOverridable f { a = 1; b = 2; }</programlisting> </section> <section xml:id="sec-pkgs-dockerTools"> - <title>pkgs.dockerTools</title> +<title>pkgs.dockerTools</title> - <para> +<para> <varname>pkgs.dockerTools</varname> is a set of functions for creating and manipulating Docker images according to the <link xlink:href="https://github.com/docker/docker/blob/master/image/spec/v1.md#docker-image-specification-v100"> - Docker Image Specification v1.0.0 + Docker Image Specification v1.0.0 </link>. Docker itself is not used to perform any of the operations done by these functions. - </para> +</para> - <warning> +<warning> <para> - The <varname>dockerTools</varname> API is unstable and may be subject to - backwards-incompatible changes in the future. + The <varname>dockerTools</varname> API is unstable and may be subject to + backwards-incompatible changes in the future. </para> - </warning> +</warning> - <section xml:id="ssec-pkgs-dockerTools-buildImage"> +<section xml:id="ssec-pkgs-dockerTools-buildImage"> <title>buildImage</title> <para> - This function is analogous to the <command>docker build</command> command, - in that can used to build a Docker-compatible repository tarball containing - a single image with one or multiple layers. As such, the result - is suitable for being loaded in Docker with <command>docker load</command>. + This function is analogous to the <command>docker build</command> command, + in that can used to build a Docker-compatible repository tarball containing + a single image with one or multiple layers. As such, the result + is suitable for being loaded in Docker with <command>docker load</command>. </para> <para> - The parameters of <varname>buildImage</varname> with relative example values are - described below: + The parameters of <varname>buildImage</varname> with relative example values are + described below: </para> <example xml:id='ex-dockerTools-buildImage'><title>Docker build</title> @@ -408,11 +451,11 @@ c = lib.makeOverridable f { a = 1; b = 2; }</programlisting> buildImage { name = "redis"; <co xml:id='ex-dockerTools-buildImage-1' /> tag = "latest"; <co xml:id='ex-dockerTools-buildImage-2' /> - + fromImage = someBaseImage; <co xml:id='ex-dockerTools-buildImage-3' /> fromImageName = null; <co xml:id='ex-dockerTools-buildImage-4' /> fromImageTag = "latest"; <co xml:id='ex-dockerTools-buildImage-5' /> - + contents = pkgs.redis; <co xml:id='ex-dockerTools-buildImage-6' /> runAsRoot = '' <co xml:id='ex-dockerTools-buildImage-runAsRoot' /> #!${stdenv.shell} @@ -431,131 +474,131 @@ c = lib.makeOverridable f { a = 1; b = 2; }</programlisting> </example> <para>The above example will build a Docker image <literal>redis/latest</literal> - from the given base image. Loading and running this image in Docker results in - <literal>redis-server</literal> being started automatically. + from the given base image. Loading and running this image in Docker results in + <literal>redis-server</literal> being started automatically. </para> <calloutlist> - <callout arearefs='ex-dockerTools-buildImage-1'> + <callout arearefs='ex-dockerTools-buildImage-1'> <para> - <varname>name</varname> specifies the name of the resulting image. - This is the only required argument for <varname>buildImage</varname>. + <varname>name</varname> specifies the name of the resulting image. + This is the only required argument for <varname>buildImage</varname>. </para> - </callout> + </callout> - <callout arearefs='ex-dockerTools-buildImage-2'> + <callout arearefs='ex-dockerTools-buildImage-2'> <para> - <varname>tag</varname> specifies the tag of the resulting image. - By default it's <literal>latest</literal>. + <varname>tag</varname> specifies the tag of the resulting image. + By default it's <literal>latest</literal>. </para> - </callout> + </callout> - <callout arearefs='ex-dockerTools-buildImage-3'> + <callout arearefs='ex-dockerTools-buildImage-3'> <para> - <varname>fromImage</varname> is the repository tarball containing the base image. - It must be a valid Docker image, such as exported by <command>docker save</command>. - By default it's <literal>null</literal>, which can be seen as equivalent - to <literal>FROM scratch</literal> of a <filename>Dockerfile</filename>. + <varname>fromImage</varname> is the repository tarball containing the base image. + It must be a valid Docker image, such as exported by <command>docker save</command>. + By default it's <literal>null</literal>, which can be seen as equivalent + to <literal>FROM scratch</literal> of a <filename>Dockerfile</filename>. </para> - </callout> - - <callout arearefs='ex-dockerTools-buildImage-4'> + </callout> + + <callout arearefs='ex-dockerTools-buildImage-4'> <para> - <varname>fromImageName</varname> can be used to further specify - the base image within the repository, in case it contains multiple images. - By default it's <literal>null</literal>, in which case - <varname>buildImage</varname> will peek the first image available - in the repository. + <varname>fromImageName</varname> can be used to further specify + the base image within the repository, in case it contains multiple images. + By default it's <literal>null</literal>, in which case + <varname>buildImage</varname> will peek the first image available + in the repository. </para> - </callout> + </callout> - <callout arearefs='ex-dockerTools-buildImage-5'> + <callout arearefs='ex-dockerTools-buildImage-5'> <para> - <varname>fromImageTag</varname> can be used to further specify the tag - of the base image within the repository, in case an image contains multiple tags. - By default it's <literal>null</literal>, in which case - <varname>buildImage</varname> will peek the first tag available for the base image. + <varname>fromImageTag</varname> can be used to further specify the tag + of the base image within the repository, in case an image contains multiple tags. + By default it's <literal>null</literal>, in which case + <varname>buildImage</varname> will peek the first tag available for the base image. </para> - </callout> + </callout> - <callout arearefs='ex-dockerTools-buildImage-6'> + <callout arearefs='ex-dockerTools-buildImage-6'> <para> - <varname>contents</varname> is a derivation that will be copied in the new - layer of the resulting image. This can be similarly seen as - <command>ADD contents/ /</command> in a <filename>Dockerfile</filename>. - By default it's <literal>null</literal>. + <varname>contents</varname> is a derivation that will be copied in the new + layer of the resulting image. This can be similarly seen as + <command>ADD contents/ /</command> in a <filename>Dockerfile</filename>. + By default it's <literal>null</literal>. </para> - </callout> + </callout> - <callout arearefs='ex-dockerTools-buildImage-runAsRoot'> + <callout arearefs='ex-dockerTools-buildImage-runAsRoot'> <para> - <varname>runAsRoot</varname> is a bash script that will run as root - in an environment that overlays the existing layers of the base image with - the new resulting layer, including the previously copied - <varname>contents</varname> derivation. - This can be similarly seen as - <command>RUN ...</command> in a <filename>Dockerfile</filename>. - - <note> + <varname>runAsRoot</varname> is a bash script that will run as root + in an environment that overlays the existing layers of the base image with + the new resulting layer, including the previously copied + <varname>contents</varname> derivation. + This can be similarly seen as + <command>RUN ...</command> in a <filename>Dockerfile</filename>. + + <note> <para> - Using this parameter requires the <literal>kvm</literal> - device to be available. + Using this parameter requires the <literal>kvm</literal> + device to be available. </para> - </note> + </note> </para> - </callout> + </callout> - <callout arearefs='ex-dockerTools-buildImage-8'> + <callout arearefs='ex-dockerTools-buildImage-8'> <para> - <varname>config</varname> is used to specify the configuration of the - containers that will be started off the built image in Docker. - The available options are listed in the - <link xlink:href="https://github.com/docker/docker/blob/master/image/spec/v1.md#container-runconfig-field-descriptions"> + <varname>config</varname> is used to specify the configuration of the + containers that will be started off the built image in Docker. + The available options are listed in the + <link xlink:href="https://github.com/docker/docker/blob/master/image/spec/v1.md#container-runconfig-field-descriptions"> Docker Image Specification v1.0.0 - </link>. + </link>. </para> - </callout> + </callout> </calloutlist> <para> - After the new layer has been created, its closure - (to which <varname>contents</varname>, <varname>config</varname> and - <varname>runAsRoot</varname> contribute) will be copied in the layer itself. - Only new dependencies that are not already in the existing layers will be copied. + After the new layer has been created, its closure + (to which <varname>contents</varname>, <varname>config</varname> and + <varname>runAsRoot</varname> contribute) will be copied in the layer itself. + Only new dependencies that are not already in the existing layers will be copied. </para> <para> - At the end of the process, only one new single layer will be produced and - added to the resulting image. + At the end of the process, only one new single layer will be produced and + added to the resulting image. </para> <para> - The resulting repository will only list the single image - <varname>image/tag</varname>. In the case of <xref linkend='ex-dockerTools-buildImage'/> - it would be <varname>redis/latest</varname>. + The resulting repository will only list the single image + <varname>image/tag</varname>. In the case of <xref linkend='ex-dockerTools-buildImage'/> + it would be <varname>redis/latest</varname>. </para> <para> - It is possible to inspect the arguments with which an image was built - using its <varname>buildArgs</varname> attribute. + It is possible to inspect the arguments with which an image was built + using its <varname>buildArgs</varname> attribute. </para> - </section> +</section> - <section xml:id="ssec-pkgs-dockerTools-fetchFromRegistry"> +<section xml:id="ssec-pkgs-dockerTools-fetchFromRegistry"> <title>pullImage</title> <para> - This function is analogous to the <command>docker pull</command> command, - in that can be used to fetch a Docker image from a Docker registry. - Currently only registry <literal>v1</literal> is supported. - By default <link xlink:href="https://hub.docker.com/">Docker Hub</link> - is used to pull images. + This function is analogous to the <command>docker pull</command> command, + in that can be used to fetch a Docker image from a Docker registry. + Currently only registry <literal>v1</literal> is supported. + By default <link xlink:href="https://hub.docker.com/">Docker Hub</link> + is used to pull images. </para> <para> - Its parameters are described in the example below: + Its parameters are described in the example below: </para> <example xml:id='ex-dockerTools-pullImage'><title>Docker pull</title> @@ -573,73 +616,73 @@ c = lib.makeOverridable f { a = 1; b = 2; }</programlisting> </example> <calloutlist> - <callout arearefs='ex-dockerTools-pullImage-1'> + <callout arearefs='ex-dockerTools-pullImage-1'> <para> - <varname>imageName</varname> specifies the name of the image to be downloaded, - which can also include the registry namespace (e.g. <literal>library/debian</literal>). - This argument is required. + <varname>imageName</varname> specifies the name of the image to be downloaded, + which can also include the registry namespace (e.g. <literal>library/debian</literal>). + This argument is required. </para> - </callout> - - <callout arearefs='ex-dockerTools-pullImage-2'> + </callout> + + <callout arearefs='ex-dockerTools-pullImage-2'> <para> - <varname>imageTag</varname> specifies the tag of the image to be downloaded. - By default it's <literal>latest</literal>. + <varname>imageTag</varname> specifies the tag of the image to be downloaded. + By default it's <literal>latest</literal>. </para> - </callout> + </callout> - <callout arearefs='ex-dockerTools-pullImage-3'> + <callout arearefs='ex-dockerTools-pullImage-3'> <para> - <varname>imageId</varname>, if specified this exact image will be fetched, instead - of <varname>imageName/imageTag</varname>. However, the resulting repository - will still be named <varname>imageName/imageTag</varname>. - By default it's <literal>null</literal>. + <varname>imageId</varname>, if specified this exact image will be fetched, instead + of <varname>imageName/imageTag</varname>. However, the resulting repository + will still be named <varname>imageName/imageTag</varname>. + By default it's <literal>null</literal>. </para> - </callout> + </callout> - <callout arearefs='ex-dockerTools-pullImage-4'> + <callout arearefs='ex-dockerTools-pullImage-4'> <para> - <varname>sha256</varname> is the checksum of the whole fetched image. - This argument is required. + <varname>sha256</varname> is the checksum of the whole fetched image. + This argument is required. </para> <note> - <para>The checksum is computed on the unpacked directory, not on the final tarball.</para> + <para>The checksum is computed on the unpacked directory, not on the final tarball.</para> </note> - </callout> + </callout> - <callout arearefs='ex-dockerTools-pullImage-5'> + <callout arearefs='ex-dockerTools-pullImage-5'> <para> - In the above example the default values are shown for the variables - <varname>indexUrl</varname> and <varname>registryVersion</varname>. - Hence by default the Docker.io registry is used to pull the images. + In the above example the default values are shown for the variables + <varname>indexUrl</varname> and <varname>registryVersion</varname>. + Hence by default the Docker.io registry is used to pull the images. </para> - </callout> + </callout> </calloutlist> - - </section> - - <section xml:id="ssec-pkgs-dockerTools-exportImage"> + +</section> + +<section xml:id="ssec-pkgs-dockerTools-exportImage"> <title>exportImage</title> <para> - This function is analogous to the <command>docker export</command> command, - in that can used to flatten a Docker image that contains multiple layers. - It is in fact the result of the merge of all the layers of the image. - As such, the result is suitable for being imported in Docker - with <command>docker import</command>. + This function is analogous to the <command>docker export</command> command, + in that can used to flatten a Docker image that contains multiple layers. + It is in fact the result of the merge of all the layers of the image. + As such, the result is suitable for being imported in Docker + with <command>docker import</command>. </para> <note> - <para> + <para> Using this function requires the <literal>kvm</literal> device to be available. - </para> + </para> </note> <para> - The parameters of <varname>exportImage</varname> are the following: + The parameters of <varname>exportImage</varname> are the following: </para> <example xml:id='ex-dockerTools-exportImage'><title>Docker export</title> @@ -648,35 +691,35 @@ c = lib.makeOverridable f { a = 1; b = 2; }</programlisting> fromImage = someLayeredImage; fromImageName = null; fromImageTag = null; - + name = someLayeredImage.name; } </programlisting> </example> <para> - The parameters relative to the base image have the same synopsis as - described in <xref linkend='ssec-pkgs-dockerTools-buildImage'/>, except that - <varname>fromImage</varname> is the only required argument in this case. + The parameters relative to the base image have the same synopsis as + described in <xref linkend='ssec-pkgs-dockerTools-buildImage'/>, except that + <varname>fromImage</varname> is the only required argument in this case. </para> <para> - The <varname>name</varname> argument is the name of the derivation output, - which defaults to <varname>fromImage.name</varname>. + The <varname>name</varname> argument is the name of the derivation output, + which defaults to <varname>fromImage.name</varname>. </para> - </section> +</section> - <section xml:id="ssec-pkgs-dockerTools-shadowSetup"> +<section xml:id="ssec-pkgs-dockerTools-shadowSetup"> <title>shadowSetup</title> <para> - This constant string is a helper for setting up the base files for managing - users and groups, only if such files don't exist already. - It is suitable for being used in a - <varname>runAsRoot</varname> <xref linkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like - in the example below: + This constant string is a helper for setting up the base files for managing + users and groups, only if such files don't exist already. + It is suitable for being used in a + <varname>runAsRoot</varname> <xref linkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like + in the example below: </para> - + <example xml:id='ex-dockerTools-shadowSetup'><title>Shadow base files</title> <programlisting> buildImage { @@ -695,13 +738,13 @@ c = lib.makeOverridable f { a = 1; b = 2; }</programlisting> </example> <para> - Creating base files like <literal>/etc/passwd</literal> or - <literal>/etc/login.defs</literal> are necessary for shadow-utils to - manipulate users and groups. + Creating base files like <literal>/etc/passwd</literal> or + <literal>/etc/login.defs</literal> are necessary for shadow-utils to + manipulate users and groups. </para> - - </section> - + +</section> + </section> </chapter> diff --git a/doc/manual.xml b/doc/manual.xml index 32e94e8e59c5..6ad66d486525 100644 --- a/doc/manual.xml +++ b/doc/manual.xml @@ -20,6 +20,7 @@ <xi:include href="package-notes.xml" /> <xi:include href="coding-conventions.xml" /> <xi:include href="submitting-changes.xml" /> + <xi:include href="reviewing-contributions.xml" /> <xi:include href="contributing.xml" /> </book> diff --git a/doc/reviewing-contributions.xml b/doc/reviewing-contributions.xml new file mode 100644 index 000000000000..f86928bcd5d0 --- /dev/null +++ b/doc/reviewing-contributions.xml @@ -0,0 +1,393 @@ +<chapter 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="sec-reviewing-contributions"> + +<title>Reviewing contributions</title> + +<warning> + <para>The following section is a draft and reviewing policy is still being + discussed.</para> +</warning> + +<para>The nixpkgs projects receives a fairly high number of contributions via + GitHub pull-requests. Reviewing and approving these is an important task and a + way to contribute to the project.</para> + +<para>The high change rate of nixpkgs make any pull request that is open for + long enough subject to conflicts that will require extra work from the + submitter or the merger. Reviewing pull requests in a timely manner and being + responsive to the comments is the key to avoid these. Github provides sort + filters that can be used to see the <link + xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc">most + recently</link> and the <link + xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc">least + recently</link> updated pull-requests.</para> + +<para>When reviewing a pull request, please always be nice and polite. + Controversial changes can lead to controversial opinions, but it is important + to respect every community members and their work.</para> + +<para>GitHub provides reactions, they are a simple and quick way to provide + feedback to pull-requests or any comments. The thumb-down reaction should be + used with care and if possible accompanied with some explanations so the + submitter has directions to improve his contribution.</para> + +<para>Pull-requests reviews should include a list of what has been reviewed in a + comment, so other reviewers and mergers can know the state of the + review.</para> + +<para>All the review template samples provided in this section are generic and + meant as examples. Their usage is optional and the reviewer is free to adapt + them to his liking.</para> + +<section><title>Package updates</title> + +<para>A package update is the most trivial and common type of pull-request. + These pull-requests mainly consist in updating the version part of the package + name and the source hash.</para> +<para>It can happen that non trivial updates include patches or more complex + changes.</para> + +<para>Reviewing process:</para> + +<itemizedlist> + <listitem><para>Add labels to the pull-request. (Requires commit + rights)</para> + <itemizedlist> + <listitem><para><literal>8.has: package (update)</literal> and any topic + label that fit the updated package.</para></listitem> + </itemizedlist> + </listitem> + <listitem><para>Ensure that the package versioning is fitting the + guidelines.</para></listitem> + <listitem><para>Ensure that the commit text is fitting the + guidelines.</para></listitem> + <listitem><para>Ensure that the package maintainers are notified.</para> + <itemizedlist> + <listitem><para>mention-bot usually notify GitHub users based on the + submitted changes, but it can happen that it misses some of the + package maintainers.</para></listitem> + </itemizedlist> + </listitem> + <listitem><para>Ensure that the meta field contains correct + information.</para> + <itemizedlist> + <listitem><para>License can change with version updates, so it should be + checked to be fitting upstream license.</para></listitem> + <listitem><para>If the package has no maintainer, a maintainer must be + set. This can be the update submitter or a community member that + accepts to take maintainership of the package.</para></listitem> + </itemizedlist> + </listitem> + <listitem><para>Ensure that the code contains no typos.</para></listitem> + <listitem><para>Building the package locally.</para> + <itemizedlist> + <listitem><para>Pull-requests are often targeted to the master or staging + branch so building the pull-request locally as it is submitted can + trigger a large amount of source builds.</para> + <para>It is possible to rebase the changes on nixos-unstable or + nixpkgs-unstable for easier review by running the following commands + from a nixpkgs clone. +<screen> +$ git remote add channels https://github.com/NixOS/nixpkgs-channels.git <co + xml:id='reviewing-rebase-1' /> +$ git fetch channels nixos-unstable <co xml:id='reviewing-rebase-2' /> +$ git fetch origin pull/PRNUMBER/head <co xml:id='reviewing-rebase-3' /> +$ git rebase --onto nixos-unstable BASEBRANCH FETCH_HEAD <co + xml:id='reviewing-rebase-4' /> +</screen> + <calloutlist> + <callout arearefs='reviewing-rebase-1'> + <para>This should be done only once to be able to fetch channel + branches from the nixpkgs-channels repository.</para> + </callout> + <callout arearefs='reviewing-rebase-2'> + <para>Fetching the nixos-unstable branch.</para> + </callout> + <callout arearefs='reviewing-rebase-3'> + <para>Fetching the pull-request changes, <varname>PRNUMBER</varname> + is the number at the end of the pull-request title and + <varname>BASEBRANCH</varname> the base branch of the + pull-request.</para> + </callout> + <callout arearefs='reviewing-rebase-3'> + <para>Rebasing the pull-request changes to the nixos-unstable + branch.</para> + </callout> + </calloutlist> + </para> + </listitem> + <listitem> + <para>The <link xlink:href="https://github.com/madjar/nox">nox</link> + tool can be used to review a pull-request content in a single command. + It doesn't rebase on a channel branch so it might trigger multiple + source builds. <varname>PRNUMBER</varname> should be replaced by the + number at the end of the pull-request title.</para> +<screen> +$ nix-shell -p nox --run "nox-review -k pr PRNUMBER" +</screen> + </listitem> + </itemizedlist> + </listitem> + <listitem><para>Running every binary.</para></listitem> +</itemizedlist> + +<example><title>Sample template for a package update review</title> +<screen> +##### Reviewed points + +- [ ] package name fits guidelines +- [ ] package version fits guidelines +- [ ] package build on ARCHITECTURE +- [ ] executables tested on ARCHITECTURE +- [ ] all depending packages build + +##### Possible improvements + +##### Comments + +</screen></example> +</section> + +<section><title>New packages</title> + +<para>New packages are a common type of pull-requests. These pull requests + consists in adding a new nix-expression for a package.</para> + +<para>Reviewing process:</para> + +<itemizedlist> + <listitem><para>Add labels to the pull-request. (Requires commit + rights)</para> + <itemizedlist> + <listitem><para><literal>8.has: package (new)</literal> and any topic + label that fit the new package.</para></listitem> + </itemizedlist> + </listitem> + <listitem><para>Ensure that the package versioning is fitting the + guidelines.</para></listitem> + <listitem><para>Ensure that the commit name is fitting the + guidelines.</para></listitem> + <listitem><para>Ensure that the meta field contains correct + information.</para> + <itemizedlist> + <listitem><para>License must be checked to be fitting upstream + license.</para></listitem> + <listitem><para>Platforms should be set or the package will not get binary + substitutes.</para></listitem> + <listitem><para>A maintainer must be set, this can be the package + submitter or a community member that accepts to take maintainership of + the package.</para></listitem> + </itemizedlist> + </listitem> + <listitem><para>Ensure that the code contains no typos.</para></listitem> + <listitem><para>Ensure the package source.</para> + <itemizedlist> + <listitem><para>Mirrors urls should be used when + available.</para></listitem> + <listitem><para>The most appropriate function should be used (e.g. + packages from GitHub should use + <literal>fetchFromGitHub</literal>).</para></listitem> + </itemizedlist> + </listitem> + <listitem><para>Building the package locally.</para></listitem> + <listitem><para>Running every binary.</para></listitem> +</itemizedlist> + +<example><title>Sample template for a new package review</title> +<screen> +##### Reviewed points + +- [ ] package path fits guidelines +- [ ] package name fits guidelines +- [ ] package version fits guidelines +- [ ] package build on ARCHITECTURE +- [ ] executables tested on ARCHITECTURE +- [ ] `meta.description` is set and fits guidelines +- [ ] `meta.license` fits upstream license +- [ ] `meta.platforms` is set +- [ ] `meta.maintainers` is set +- [ ] build time only dependencies are declared in `nativeBuildInputs` +- [ ] source is fetched using the appropriate function +- [ ] phases are respected +- [ ] patches that are remotely available are fetched with `fetchpatch` + +##### Possible improvements + +##### Comments + +</screen></example> +</section> + +<section><title>Module updates</title> + +<para>Module updates are submissions changing modules in some ways. These often + contains changes to the options or introduce new options.</para> + +<para>Reviewing process</para> + +<itemizedlist> + <listitem><para>Add labels to the pull-request. (Requires commit + rights)</para> + <itemizedlist> + <listitem><para><literal>8.has: module (update)</literal> and any topic + label that fit the module.</para></listitem> + </itemizedlist> + </listitem> + <listitem><para>Ensure that the module maintainers are notified.</para> + <itemizedlist> + <listitem><para>Mention-bot notify GitHub users based on the submitted + changes, but it can happen that it miss some of the package + maintainers.</para></listitem> + </itemizedlist> + </listitem> + <listitem><para>Ensure that the module tests, if any, are + succeeding.</para></listitem> + <listitem><para>Ensure that the introduced options are correct.</para> + <itemizedlist> + <listitem><para>Type should be appropriate (string related types differs + in their merging capabilities, <literal>optionSet</literal> and + <literal>string</literal> types are deprecated).</para></listitem> + <listitem><para>Description, default and example should be + provided.</para></listitem> + </itemizedlist> + </listitem> + <listitem><para>Ensure that option changes are backward compatible.</para> + <itemizedlist> + <listitem><para><literal>mkRenamedOptionModule</literal> and + <literal>mkAliasOptionModule</literal> functions provide way to make + option changes backward compatible.</para></listitem> + </itemizedlist> + </listitem> + <listitem><para>Ensure that removed options are declared with + <literal>mkRemovedOptionModule</literal></para></listitem> + <listitem><para>Ensure that changes that are not backward compatible are + mentioned in release notes.</para></listitem> + <listitem><para>Ensure that documentations affected by the change is + updated.</para></listitem> +</itemizedlist> + +<example><title>Sample template for a module update review</title> +<screen> +##### Reviewed points + +- [ ] changes are backward compatible +- [ ] removed options are declared with `mkRemovedOptionModule` +- [ ] changes that are not backward compatible are documented in release notes +- [ ] module tests succeed on ARCHITECTURE +- [ ] options types are appropriate +- [ ] options description is set +- [ ] options example is provided +- [ ] documentation affected by the changes is updated + +##### Possible improvements + +##### Comments + +</screen></example> +</section> + +<section><title>New modules</title> + +<para>New modules submissions introduce a new module to NixOS.</para> + +<itemizedlist> + <listitem><para>Add labels to the pull-request. (Requires commit + rights)</para> + <itemizedlist> + <listitem><para><literal>8.has: module (new)</literal> and any topic label + that fit the module.</para></listitem> + </itemizedlist> + </listitem> + <listitem><para>Ensure that the module tests, if any, are + succeeding.</para></listitem> + <listitem><para>Ensure that the introduced options are correct.</para> + <itemizedlist> + <listitem><para>Type should be appropriate (string related types differs + in their merging capabilities, <literal>optionSet</literal> and + <literal>string</literal> types are deprecated).</para></listitem> + <listitem><para>Description, default and example should be + provided.</para></listitem> + </itemizedlist> + </listitem> + <listitem><para>Ensure that module <literal>meta</literal> field is + present</para> + <itemizedlist> + <listitem><para>Maintainers should be declared in + <literal>meta.maintainers</literal>.</para></listitem> + <listitem><para>Module documentation should be declared with + <literal>meta.doc</literal>.</para></listitem> + </itemizedlist> + </listitem> + <listitem><para>Ensure that the module respect other modules + functionality.</para> + <itemizedlist> + <listitem><para>For example, enabling a module should not open firewall + ports by default.</para></listitem> + </itemizedlist> + </listitem> +</itemizedlist> + +<example><title>Sample template for a new module review</title> +<screen> +##### Reviewed points + +- [ ] module path fits the guidelines +- [ ] module tests succeed on ARCHITECTURE +- [ ] options have appropriate types +- [ ] options have default +- [ ] options have example +- [ ] options have descriptions +- [ ] No unneeded package is added to system.environmentPackages +- [ ] meta.maintainers is set +- [ ] module documentation is declared in meta.doc + +##### Possible improvements + +##### Comments + +</screen></example> +</section> + +<section><title>Other submissions</title> + +<para>Other type of submissions requires different reviewing steps.</para> + +<para>If you consider having enough knowledge and experience in a topic and + would like to be a long-term reviewer for related submissions, please contact + the current reviewers for that topic. They will give you information about the + reviewing process. +The main reviewers for a topic can be hard to find as there is no list, but +checking past pull-requests to see who reviewed or git-blaming the code to see +who committed to that topic can give some hints.</para> + +<para>Container system, boot system and library changes are some examples of the + pull requests fitting this category.</para> + +</section> + +<section><title>Merging pull-requests</title> + +<para>It is possible for community members that have enough knowledge and + experience on a special topic to contribute by merging pull requests.</para> + +<para>TODO: add the procedure to request merging rights.</para> + +<!-- +The following paragraph about how to deal with unactive contributors is just a +proposition and should be modified to what the community agrees to be the right +policy. + +<para>Please note that contributors with commit rights unactive for more than + three months will have their commit rights revoked.</para> +--> + +<para>In a case a contributor leaves definitively the Nix community, he should + create an issue or notify the mailing list with references of packages and + modules he maintains so the maintainership can be taken over by other + contributors.</para> + +</section> +</chapter> |