nixpkgs docs: Reformat
This commit is contained in:
parent
444e04b985
commit
c07ba7c856
|
@ -47,9 +47,10 @@
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In Nixpkgs, these three platforms are defined as attribute sets under the
|
In Nixpkgs, these three platforms are defined as attribute sets under the
|
||||||
names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>, and
|
names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>,
|
||||||
<literal>targetPlatform</literal>. They are always defined as attributes in
|
and <literal>targetPlatform</literal>. They are always defined as
|
||||||
the standard environment. That means one can access them like:
|
attributes in the standard environment. That means one can access them
|
||||||
|
like:
|
||||||
<programlisting>{ stdenv, fooDep, barDep, .. }: ...stdenv.buildPlatform...</programlisting>
|
<programlisting>{ stdenv, fooDep, barDep, .. }: ...stdenv.buildPlatform...</programlisting>
|
||||||
.
|
.
|
||||||
</para>
|
</para>
|
||||||
|
|
|
@ -13,9 +13,9 @@
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In the <literal>lib/debug.nix</literal> file you will find a number of
|
In the <literal>lib/debug.nix</literal> file you will find a number of
|
||||||
functions that help (pretty-)printing values while evaluation is runnnig.
|
functions that help (pretty-)printing values while evaluation is runnnig. You
|
||||||
You can even specify how deep these values should be printed recursively,
|
can even specify how deep these values should be printed recursively, and
|
||||||
and transform them on the fly. Please consult the docstrings in
|
transform them on the fly. Please consult the docstrings in
|
||||||
<literal>lib/debug.nix</literal> for usage information.
|
<literal>lib/debug.nix</literal> for usage information.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
|
@ -30,8 +30,8 @@
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The parameters of <varname>buildImage</varname> with relative example
|
The parameters of <varname>buildImage</varname> with relative example values
|
||||||
values are described below:
|
are described below:
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<example xml:id='ex-dockerTools-buildImage'>
|
<example xml:id='ex-dockerTools-buildImage'>
|
||||||
|
@ -71,8 +71,8 @@ buildImage {
|
||||||
<calloutlist>
|
<calloutlist>
|
||||||
<callout arearefs='ex-dockerTools-buildImage-1'>
|
<callout arearefs='ex-dockerTools-buildImage-1'>
|
||||||
<para>
|
<para>
|
||||||
<varname>name</varname> specifies the name of the resulting image. This
|
<varname>name</varname> specifies the name of the resulting image. This is
|
||||||
is the only required argument for <varname>buildImage</varname>.
|
the only required argument for <varname>buildImage</varname>.
|
||||||
</para>
|
</para>
|
||||||
</callout>
|
</callout>
|
||||||
<callout arearefs='ex-dockerTools-buildImage-2'>
|
<callout arearefs='ex-dockerTools-buildImage-2'>
|
||||||
|
@ -84,8 +84,8 @@ buildImage {
|
||||||
</callout>
|
</callout>
|
||||||
<callout arearefs='ex-dockerTools-buildImage-3'>
|
<callout arearefs='ex-dockerTools-buildImage-3'>
|
||||||
<para>
|
<para>
|
||||||
<varname>fromImage</varname> is the repository tarball containing the
|
<varname>fromImage</varname> is the repository tarball containing the base
|
||||||
base image. It must be a valid Docker image, such as exported by
|
image. It must be a valid Docker image, such as exported by
|
||||||
<command>docker save</command>. By default it's <literal>null</literal>,
|
<command>docker save</command>. By default it's <literal>null</literal>,
|
||||||
which can be seen as equivalent to <literal>FROM scratch</literal> of a
|
which can be seen as equivalent to <literal>FROM scratch</literal> of a
|
||||||
<filename>Dockerfile</filename>.
|
<filename>Dockerfile</filename>.
|
||||||
|
@ -111,10 +111,10 @@ buildImage {
|
||||||
</callout>
|
</callout>
|
||||||
<callout arearefs='ex-dockerTools-buildImage-6'>
|
<callout arearefs='ex-dockerTools-buildImage-6'>
|
||||||
<para>
|
<para>
|
||||||
<varname>contents</varname> is a derivation that will be copied in the
|
<varname>contents</varname> is a derivation that will be copied in the new
|
||||||
new layer of the resulting image. This can be similarly seen as
|
layer of the resulting image. This can be similarly seen as <command>ADD
|
||||||
<command>ADD contents/ /</command> in a <filename>Dockerfile</filename>.
|
contents/ /</command> in a <filename>Dockerfile</filename>. By default
|
||||||
By default it's <literal>null</literal>.
|
it's <literal>null</literal>.
|
||||||
</para>
|
</para>
|
||||||
</callout>
|
</callout>
|
||||||
<callout arearefs='ex-dockerTools-buildImage-runAsRoot'>
|
<callout arearefs='ex-dockerTools-buildImage-runAsRoot'>
|
||||||
|
@ -146,9 +146,9 @@ buildImage {
|
||||||
<para>
|
<para>
|
||||||
After the new layer has been created, its closure (to which
|
After the new layer has been created, its closure (to which
|
||||||
<varname>contents</varname>, <varname>config</varname> and
|
<varname>contents</varname>, <varname>config</varname> and
|
||||||
<varname>runAsRoot</varname> contribute) will be copied in the layer
|
<varname>runAsRoot</varname> contribute) will be copied in the layer itself.
|
||||||
itself. Only new dependencies that are not already in the existing layers
|
Only new dependencies that are not already in the existing layers will be
|
||||||
will be copied.
|
copied.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
@ -170,8 +170,8 @@ buildImage {
|
||||||
|
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
If you see errors similar to <literal>getProtocolByName: does not exist
|
If you see errors similar to <literal>getProtocolByName: does not exist (no
|
||||||
(no such protocol name: tcp)</literal> you may need to add
|
such protocol name: tcp)</literal> you may need to add
|
||||||
<literal>pkgs.iana-etc</literal> to <varname>contents</varname>.
|
<literal>pkgs.iana-etc</literal> to <varname>contents</varname>.
|
||||||
</para>
|
</para>
|
||||||
</note>
|
</note>
|
||||||
|
@ -187,12 +187,11 @@ buildImage {
|
||||||
<example xml:id="example-pkgs-dockerTools-buildImage-creation-date">
|
<example xml:id="example-pkgs-dockerTools-buildImage-creation-date">
|
||||||
<title>Impurely Defining a Docker Layer's Creation Date</title>
|
<title>Impurely Defining a Docker Layer's Creation Date</title>
|
||||||
<para>
|
<para>
|
||||||
By default <function>buildImage</function> will use a static
|
By default <function>buildImage</function> will use a static date of one
|
||||||
date of one second past the UNIX Epoch. This allows
|
second past the UNIX Epoch. This allows <function>buildImage</function> to
|
||||||
<function>buildImage</function> to produce binary reproducible
|
produce binary reproducible images. When listing images with
|
||||||
images. When listing images with <command>docker list
|
<command>docker list images</command>, the newly created images will be
|
||||||
images</command>, the newly created images will be listed like
|
listed like this:
|
||||||
this:
|
|
||||||
</para>
|
</para>
|
||||||
<screen><![CDATA[
|
<screen><![CDATA[
|
||||||
$ docker image list
|
$ docker image list
|
||||||
|
@ -200,9 +199,9 @@ REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||||
hello latest 08c791c7846e 48 years ago 25.2MB
|
hello latest 08c791c7846e 48 years ago 25.2MB
|
||||||
]]></screen>
|
]]></screen>
|
||||||
<para>
|
<para>
|
||||||
You can break binary reproducibility but have a sorted,
|
You can break binary reproducibility but have a sorted, meaningful
|
||||||
meaningful <literal>CREATED</literal> column by setting
|
<literal>CREATED</literal> column by setting <literal>created</literal> to
|
||||||
<literal>created</literal> to <literal>now</literal>.
|
<literal>now</literal>.
|
||||||
</para>
|
</para>
|
||||||
<programlisting><![CDATA[
|
<programlisting><![CDATA[
|
||||||
pkgs.dockerTools.buildImage {
|
pkgs.dockerTools.buildImage {
|
||||||
|
@ -215,8 +214,8 @@ pkgs.dockerTools.buildImage {
|
||||||
}
|
}
|
||||||
]]></programlisting>
|
]]></programlisting>
|
||||||
<para>
|
<para>
|
||||||
and now the Docker CLI will display a reasonable date and
|
and now the Docker CLI will display a reasonable date and sort the images
|
||||||
sort the images as expected:
|
as expected:
|
||||||
<screen><![CDATA[
|
<screen><![CDATA[
|
||||||
$ docker image list
|
$ docker image list
|
||||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||||
|
@ -380,8 +379,8 @@ pkgs.dockerTools.buildLayeredImage {
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
If the produced image will not be extended by other Docker builds, it is
|
If the produced image will not be extended by other Docker builds, it is
|
||||||
safe to set <varname>maxLayers</varname> to <literal>128</literal>.
|
safe to set <varname>maxLayers</varname> to <literal>128</literal>. However
|
||||||
However it will be impossible to extend the image further.
|
it will be impossible to extend the image further.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
@ -402,10 +401,10 @@ pkgs.dockerTools.buildLayeredImage {
|
||||||
<title>pullImage</title>
|
<title>pullImage</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This function is analogous to the <command>docker pull</command> command,
|
This function is analogous to the <command>docker pull</command> command, in
|
||||||
in that can be used to pull a Docker image from a Docker registry. By
|
that can be used to pull a Docker image from a Docker registry. By default
|
||||||
default <link xlink:href="https://hub.docker.com/">Docker Hub</link> is
|
<link xlink:href="https://hub.docker.com/">Docker Hub</link> is used to pull
|
||||||
used to pull images.
|
images.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
@ -439,8 +438,8 @@ pullImage {
|
||||||
<varname>imageDigest</varname> specifies the digest of the image to be
|
<varname>imageDigest</varname> specifies the digest of the image to be
|
||||||
downloaded. Skopeo can be used to get the digest of an image, with its
|
downloaded. Skopeo can be used to get the digest of an image, with its
|
||||||
<varname>inspect</varname> subcommand. Since a given
|
<varname>inspect</varname> subcommand. Since a given
|
||||||
<varname>imageName</varname> may transparently refer to a manifest list
|
<varname>imageName</varname> may transparently refer to a manifest list of
|
||||||
of images which support multiple architectures and/or operating systems,
|
images which support multiple architectures and/or operating systems,
|
||||||
supply the `--override-os` and `--override-arch` arguments to specify
|
supply the `--override-os` and `--override-arch` arguments to specify
|
||||||
exactly which image you want. By default it will match the OS and
|
exactly which image you want. By default it will match the OS and
|
||||||
architecture of the host the command is run on.
|
architecture of the host the command is run on.
|
||||||
|
@ -461,8 +460,8 @@ sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b
|
||||||
</callout>
|
</callout>
|
||||||
<callout arearefs='ex-dockerTools-pullImage-4'>
|
<callout arearefs='ex-dockerTools-pullImage-4'>
|
||||||
<para>
|
<para>
|
||||||
<varname>sha256</varname> is the checksum of the whole fetched image.
|
<varname>sha256</varname> is the checksum of the whole fetched image. This
|
||||||
This argument is required.
|
argument is required.
|
||||||
</para>
|
</para>
|
||||||
</callout>
|
</callout>
|
||||||
<callout arearefs='ex-dockerTools-pullImage-5'>
|
<callout arearefs='ex-dockerTools-pullImage-5'>
|
||||||
|
@ -485,10 +484,10 @@ sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This function is analogous to the <command>docker export</command> 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.
|
in that can used to flatten a Docker image that contains multiple layers. It
|
||||||
It is in fact the result of the merge of all the layers of the image. As
|
is in fact the result of the merge of all the layers of the image. As such,
|
||||||
such, the result is suitable for being imported in Docker with
|
the result is suitable for being imported in Docker with <command>docker
|
||||||
<command>docker import</command>.
|
import</command>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<note>
|
<note>
|
||||||
|
@ -517,9 +516,8 @@ exportImage {
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The parameters relative to the base image have the same synopsis as
|
The parameters relative to the base image have the same synopsis as
|
||||||
described in <xref linkend='ssec-pkgs-dockerTools-buildImage'/>, except
|
described in <xref linkend='ssec-pkgs-dockerTools-buildImage'/>, except that
|
||||||
that <varname>fromImage</varname> is the only required argument in this
|
<varname>fromImage</varname> is the only required argument in this case.
|
||||||
case.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
@ -533,8 +531,8 @@ exportImage {
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This constant string is a helper for setting up the base files for managing
|
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
|
users and groups, only if such files don't exist already. It is suitable for
|
||||||
for being used in a <varname>runAsRoot</varname>
|
being used in a <varname>runAsRoot</varname>
|
||||||
<xref linkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like
|
<xref linkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like
|
||||||
in the example below:
|
in the example below:
|
||||||
</para>
|
</para>
|
||||||
|
|
|
@ -9,12 +9,11 @@
|
||||||
FHS-compatible lightweight sandboxes. It creates an isolated root with bound
|
FHS-compatible lightweight sandboxes. It creates an isolated root with bound
|
||||||
<filename>/nix/store</filename>, so its footprint in terms of disk space
|
<filename>/nix/store</filename>, so its footprint in terms of disk space
|
||||||
needed is quite small. This allows one to run software which is hard or
|
needed is quite small. This allows one to run software which is hard or
|
||||||
unfeasible to patch for NixOS -- 3rd-party source trees with FHS
|
unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions,
|
||||||
assumptions, games distributed as tarballs, software with integrity checking
|
games distributed as tarballs, software with integrity checking and/or
|
||||||
and/or external self-updated binaries. It uses Linux namespaces feature to
|
external self-updated binaries. It uses Linux namespaces feature to create
|
||||||
create temporary lightweight environments which are destroyed after all
|
temporary lightweight environments which are destroyed after all child
|
||||||
child processes exit, without root user rights requirement. Accepted
|
processes exit, without root user rights requirement. Accepted arguments are:
|
||||||
arguments are:
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<variablelist>
|
<variablelist>
|
||||||
|
@ -57,8 +56,7 @@
|
||||||
</term>
|
</term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
Additional commands to be executed for finalizing the directory
|
Additional commands to be executed for finalizing the directory structure.
|
||||||
structure.
|
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
@ -109,8 +107,8 @@
|
||||||
</variablelist>
|
</variablelist>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
One can create a simple environment using a <literal>shell.nix</literal>
|
One can create a simple environment using a <literal>shell.nix</literal> like
|
||||||
like that:
|
that:
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<programlisting><![CDATA[
|
<programlisting><![CDATA[
|
||||||
|
@ -136,9 +134,9 @@
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Running <literal>nix-shell</literal> would then drop you into a shell with
|
Running <literal>nix-shell</literal> would then drop you into a shell with
|
||||||
these libraries and binaries available. You can use this to run
|
these libraries and binaries available. You can use this to run closed-source
|
||||||
closed-source applications which expect FHS structure without hassles:
|
applications which expect FHS structure without hassles: simply change
|
||||||
simply change <literal>runScript</literal> to the application path, e.g.
|
<literal>runScript</literal> to the application path, e.g.
|
||||||
<filename>./bin/start.sh</filename> -- relative paths are supported.
|
<filename>./bin/start.sh</filename> -- relative paths are supported.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
|
@ -14,12 +14,11 @@
|
||||||
All generators follow a similar call interface: <code>generatorName
|
All generators follow a similar call interface: <code>generatorName
|
||||||
configFunctions data</code>, where <literal>configFunctions</literal> is an
|
configFunctions data</code>, where <literal>configFunctions</literal> is an
|
||||||
attrset of user-defined functions that format nested parts of the content.
|
attrset of user-defined functions that format nested parts of the content.
|
||||||
They each have common defaults, so often they do not need to be set
|
They each have common defaults, so often they do not need to be set manually.
|
||||||
manually. An example is <code>mkSectionName ? (name: libStr.escape [ "[" "]"
|
An example is <code>mkSectionName ? (name: libStr.escape [ "[" "]" ]
|
||||||
] name)</code> from the <literal>INI</literal> generator. It receives the
|
name)</code> from the <literal>INI</literal> generator. It receives the name
|
||||||
name of a section and sanitizes it. The default
|
of a section and sanitizes it. The default <literal>mkSectionName</literal>
|
||||||
<literal>mkSectionName</literal> escapes <literal>[</literal> and
|
escapes <literal>[</literal> and <literal>]</literal> with a backslash.
|
||||||
<literal>]</literal> with a backslash.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
|
|
@ -81,17 +81,16 @@ helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
Note that <varname>separateDebugInfo</varname> is processed only by the
|
Note that <varname>separateDebugInfo</varname> is processed only by the
|
||||||
<varname>stdenv.mkDerivation</varname> function, not the generated, raw
|
<varname>stdenv.mkDerivation</varname> function, not the generated, raw Nix
|
||||||
Nix derivation. Thus, using <varname>overrideDerivation</varname> will not
|
derivation. Thus, using <varname>overrideDerivation</varname> will not work
|
||||||
work in this case, as it overrides only the attributes of the final
|
in this case, as it overrides only the attributes of the final derivation.
|
||||||
derivation. It is for this reason that <varname>overrideAttrs</varname>
|
It is for this reason that <varname>overrideAttrs</varname> should be
|
||||||
should be preferred in (almost) all cases to
|
preferred in (almost) all cases to <varname>overrideDerivation</varname>,
|
||||||
<varname>overrideDerivation</varname>, i.e. to allow using
|
i.e. to allow using <varname>sdenv.mkDerivation</varname> to process input
|
||||||
<varname>sdenv.mkDerivation</varname> to process input arguments, as well
|
arguments, as well as the fact that it is easier to use (you can use the
|
||||||
as the fact that it is easier to use (you can use the same attribute names
|
same attribute names you see in your Nix code, instead of the ones
|
||||||
you see in your Nix code, instead of the ones generated (e.g.
|
generated (e.g. <varname>buildInputs</varname> vs
|
||||||
<varname>buildInputs</varname> vs <varname>nativeBuildInputs</varname>,
|
<varname>nativeBuildInputs</varname>, and involves less typing.
|
||||||
and involves less typing.
|
|
||||||
</para>
|
</para>
|
||||||
</note>
|
</note>
|
||||||
</section>
|
</section>
|
||||||
|
@ -101,8 +100,8 @@ helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
|
||||||
|
|
||||||
<warning>
|
<warning>
|
||||||
<para>
|
<para>
|
||||||
You should prefer <varname>overrideAttrs</varname> in almost all cases,
|
You should prefer <varname>overrideAttrs</varname> in almost all cases, see
|
||||||
see its documentation for the reasons why.
|
its documentation for the reasons why.
|
||||||
<varname>overrideDerivation</varname> is not deprecated and will continue
|
<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
|
to work, but is less nice to use and does not have as many abilities as
|
||||||
<varname>overrideAttrs</varname>.
|
<varname>overrideAttrs</varname>.
|
||||||
|
@ -115,18 +114,17 @@ helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
|
||||||
modifying it, which breaks package abstraction and removes error-checking
|
modifying it, which breaks package abstraction and removes error-checking
|
||||||
of function arguments. In addition, this evaluation-per-function
|
of function arguments. In addition, this evaluation-per-function
|
||||||
application incurs a performance penalty, which can become a problem if
|
application incurs a performance penalty, which can become a problem if
|
||||||
many overrides are used. It is only intended for ad-hoc customisation,
|
many overrides are used. It is only intended for ad-hoc customisation, such
|
||||||
such as in <filename>~/.config/nixpkgs/config.nix</filename>.
|
as in <filename>~/.config/nixpkgs/config.nix</filename>.
|
||||||
</para>
|
</para>
|
||||||
</warning>
|
</warning>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The function <varname>overrideDerivation</varname> creates a new derivation
|
The function <varname>overrideDerivation</varname> creates a new derivation
|
||||||
based on an existing one by overriding the original's attributes with the
|
based on an existing one by overriding the original's attributes with the
|
||||||
attribute set produced by the specified function. This function is
|
attribute set produced by the specified function. This function is available
|
||||||
available on all derivations defined using the
|
on all derivations defined using the <varname>makeOverridable</varname>
|
||||||
<varname>makeOverridable</varname> function. Most standard
|
function. Most standard derivation-producing functions, such as
|
||||||
derivation-producing functions, such as
|
|
||||||
<varname>stdenv.mkDerivation</varname>, are defined using this function,
|
<varname>stdenv.mkDerivation</varname>, are defined using this function,
|
||||||
which means most packages in the nixpkgs expression,
|
which means most packages in the nixpkgs expression,
|
||||||
<varname>pkgs</varname>, have this function.
|
<varname>pkgs</varname>, have this function.
|
||||||
|
@ -197,8 +195,8 @@ c = lib.makeOverridable f { a = 1; b = 2; };
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The variable <varname>c</varname> however also has some additional
|
The variable <varname>c</varname> however also has some additional
|
||||||
functions, like <link linkend="sec-pkg-override">c.override</link> which
|
functions, like <link linkend="sec-pkg-override">c.override</link> which can
|
||||||
can be used to override the default arguments. In this example the value of
|
be used to override the default arguments. In this example the value of
|
||||||
<varname>(c.override { a = 4; }).result</varname> is 6.
|
<varname>(c.override { a = 4; }).result</varname> is 6.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
|
@ -5,10 +5,9 @@
|
||||||
<title>pkgs.mkShell</title>
|
<title>pkgs.mkShell</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<function>pkgs.mkShell</function> is a special kind of derivation
|
<function>pkgs.mkShell</function> is a special kind of derivation that is
|
||||||
that is only useful when using it combined with
|
only useful when using it combined with <command>nix-shell</command>. It will
|
||||||
<command>nix-shell</command>. It will in fact fail to instantiate
|
in fact fail to instantiate when invoked with <command>nix-build</command>.
|
||||||
when invoked with <command>nix-build</command>.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<section xml:id="sec-pkgs-mkShell-usage">
|
<section xml:id="sec-pkgs-mkShell-usage">
|
||||||
|
|
|
@ -671,8 +671,9 @@ overrides = self: super: rec {
|
||||||
plugins = with availablePlugins; [ python perl ];
|
plugins = with availablePlugins; [ python perl ];
|
||||||
}
|
}
|
||||||
}</programlisting>
|
}</programlisting>
|
||||||
If the <literal>configure</literal> function returns an attrset without the <literal>plugins</literal>
|
If the <literal>configure</literal> function returns an attrset without the
|
||||||
attribute, <literal>availablePlugins</literal> will be used automatically.
|
<literal>plugins</literal> attribute, <literal>availablePlugins</literal>
|
||||||
|
will be used automatically.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
@ -706,9 +707,11 @@ overrides = self: super: rec {
|
||||||
}; }
|
}; }
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
WeeChat allows to set defaults on startup using the <literal>--run-command</literal>.
|
WeeChat allows to set defaults on startup using the
|
||||||
The <literal>configure</literal> method can be used to pass commands to the program:
|
<literal>--run-command</literal>. The <literal>configure</literal> method
|
||||||
|
can be used to pass commands to the program:
|
||||||
<programlisting>weechat.override {
|
<programlisting>weechat.override {
|
||||||
configure = { availablePlugins, ... }: {
|
configure = { availablePlugins, ... }: {
|
||||||
init = ''
|
init = ''
|
||||||
|
@ -720,9 +723,11 @@ overrides = self: super: rec {
|
||||||
Further values can be added to the list of commands when running
|
Further values can be added to the list of commands when running
|
||||||
<literal>weechat --run-command "your-commands"</literal>.
|
<literal>weechat --run-command "your-commands"</literal>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Additionally it's possible to specify scripts to be loaded when starting <literal>weechat</literal>.
|
Additionally it's possible to specify scripts to be loaded when starting
|
||||||
These will be loaded before the commands from <literal>init</literal>:
|
<literal>weechat</literal>. These will be loaded before the commands from
|
||||||
|
<literal>init</literal>:
|
||||||
<programlisting>weechat.override {
|
<programlisting>weechat.override {
|
||||||
configure = { availablePlugins, ... }: {
|
configure = { availablePlugins, ... }: {
|
||||||
scripts = with pkgs.weechatScripts; [
|
scripts = with pkgs.weechatScripts; [
|
||||||
|
@ -734,11 +739,13 @@ overrides = self: super: rec {
|
||||||
};
|
};
|
||||||
}</programlisting>
|
}</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In <literal>nixpkgs</literal> there's a subpackage which contains derivations for
|
In <literal>nixpkgs</literal> there's a subpackage which contains
|
||||||
WeeChat scripts. Such derivations expect a <literal>passthru.scripts</literal> attribute
|
derivations for WeeChat scripts. Such derivations expect a
|
||||||
which contains a list of all scripts inside the store path. Furthermore all scripts
|
<literal>passthru.scripts</literal> attribute which contains a list of all
|
||||||
have to live in <literal>$out/share</literal>. An exemplary derivation looks like this:
|
scripts inside the store path. Furthermore all scripts have to live in
|
||||||
|
<literal>$out/share</literal>. An exemplary derivation looks like this:
|
||||||
<programlisting>{ stdenv, fetchurl }:
|
<programlisting>{ stdenv, fetchurl }:
|
||||||
|
|
||||||
stdenv.mkDerivation {
|
stdenv.mkDerivation {
|
||||||
|
@ -817,20 +824,26 @@ citrix_receiver.override {
|
||||||
<section xml:id="sec-ibus-typing-booster">
|
<section xml:id="sec-ibus-typing-booster">
|
||||||
<title>ibus-engines.typing-booster</title>
|
<title>ibus-engines.typing-booster</title>
|
||||||
|
|
||||||
<para>This package is an ibus-based completion method to speed up typing.</para>
|
<para>
|
||||||
|
This package is an ibus-based completion method to speed up typing.
|
||||||
|
</para>
|
||||||
|
|
||||||
<section xml:id="sec-ibus-typing-booster-activate">
|
<section xml:id="sec-ibus-typing-booster-activate">
|
||||||
<title>Activating the engine</title>
|
<title>Activating the engine</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
IBus needs to be configured accordingly to activate <literal>typing-booster</literal>. The configuration
|
IBus needs to be configured accordingly to activate
|
||||||
depends on the desktop manager in use. For detailed instructions, please refer to the
|
<literal>typing-booster</literal>. The configuration depends on the desktop
|
||||||
<link xlink:href="https://mike-fabian.github.io/ibus-typing-booster/documentation.html">upstream docs</link>.
|
manager in use. For detailed instructions, please refer to the
|
||||||
|
<link xlink:href="https://mike-fabian.github.io/ibus-typing-booster/documentation.html">upstream
|
||||||
|
docs</link>.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
On NixOS you need to explicitly enable <literal>ibus</literal> with given engines
|
On NixOS you need to explicitly enable <literal>ibus</literal> with given
|
||||||
before customizing your desktop to use <literal>typing-booster</literal>. This can be achieved
|
engines before customizing your desktop to use
|
||||||
using the <literal>ibus</literal> module:
|
<literal>typing-booster</literal>. This can be achieved using the
|
||||||
|
<literal>ibus</literal> module:
|
||||||
<programlisting>{ pkgs, ... }: {
|
<programlisting>{ pkgs, ... }: {
|
||||||
i18n.inputMethod = {
|
i18n.inputMethod = {
|
||||||
enabled = "ibus";
|
enabled = "ibus";
|
||||||
|
@ -844,17 +857,20 @@ citrix_receiver.override {
|
||||||
<title>Using custom hunspell dictionaries</title>
|
<title>Using custom hunspell dictionaries</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The IBus engine is based on <literal>hunspell</literal> to support completion in many languages.
|
The IBus engine is based on <literal>hunspell</literal> to support
|
||||||
By default the dictionaries <literal>de-de</literal>, <literal>en-us</literal>, <literal>es-es</literal>,
|
completion in many languages. By default the dictionaries
|
||||||
<literal>it-it</literal>, <literal>sv-se</literal> and <literal>sv-fi</literal>
|
<literal>de-de</literal>, <literal>en-us</literal>,
|
||||||
are in use. To add another dictionary, the package can be overridden like this:
|
<literal>es-es</literal>, <literal>it-it</literal>,
|
||||||
|
<literal>sv-se</literal> and <literal>sv-fi</literal> are in use. To add
|
||||||
|
another dictionary, the package can be overridden like this:
|
||||||
<programlisting>ibus-engines.typing-booster.override {
|
<programlisting>ibus-engines.typing-booster.override {
|
||||||
langs = [ "de-at" "en-gb" ];
|
langs = [ "de-at" "en-gb" ];
|
||||||
}</programlisting>
|
}</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<emphasis>Note: each language passed to <literal>langs</literal> must be an attribute name in
|
<emphasis>Note: each language passed to <literal>langs</literal> must be an
|
||||||
<literal>pkgs.hunspellDicts</literal>.</emphasis>
|
attribute name in <literal>pkgs.hunspellDicts</literal>.</emphasis>
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
|
@ -862,10 +878,12 @@ citrix_receiver.override {
|
||||||
<title>Built-in emoji picker</title>
|
<title>Built-in emoji picker</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The <literal>ibus-engines.typing-booster</literal> package contains a program
|
The <literal>ibus-engines.typing-booster</literal> package contains a
|
||||||
named <literal>emoji-picker</literal>. To display all emojis correctly,
|
program named <literal>emoji-picker</literal>. To display all emojis
|
||||||
a special font such as <literal>noto-fonts-emoji</literal> is needed:
|
correctly, a special font such as <literal>noto-fonts-emoji</literal> is
|
||||||
|
needed:
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
On NixOS it can be installed using the following expression:
|
On NixOS it can be installed using the following expression:
|
||||||
<programlisting>{ pkgs, ... }: {
|
<programlisting>{ pkgs, ... }: {
|
||||||
|
|
Loading…
Reference in a new issue