path: root/doc/functions.xml

<chapter xmlns="http://docbook.org/ns/docbook"
         xmlns:xlink="http://www.w3.org/1999/xlink"
         xmlns:xi="http://www.w3.org/2001/XInclude"
         xml:id="chap-functions">
 <title>Functions reference</title>
 <para>
  The nixpkgs repository has several utility functions to manipulate Nix
  expressions.
 </para>

 <xi:include href="functions/overrides.xml" />
 <xi:include href="functions/generators.xml" />
 <xi:include href="functions/debug.xml" />
 <section xml:id="sec-fhs-environments">
  <title>buildFHSUserEnv</title>

  <para>
   <function>buildFHSUserEnv</function> provides a way to build and run
   FHS-compatible lightweight sandboxes. It creates an isolated root with bound
   <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
   unfeasible to patch for NixOS -- 3rd-party source trees with FHS
   assumptions, games distributed as tarballs, software with integrity checking
   and/or external self-updated binaries. It uses Linux namespaces feature to
   create temporary lightweight environments which are destroyed after all
   child processes exit, without root user rights requirement. Accepted
   arguments are:
  </para>

  <variablelist>
   <varlistentry>
    <term>
     <literal>name</literal>
    </term>
    <listitem>
     <para>
      Environment name.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>
     <literal>targetPkgs</literal>
    </term>
    <listitem>
     <para>
      Packages to be installed for the main host's architecture (i.e. x86_64 on
      x86_64 installations). Along with libraries binaries are also installed.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>
     <literal>multiPkgs</literal>
    </term>
    <listitem>
     <para>
      Packages to be installed for all architectures supported by a host (i.e.
      i686 and x86_64 on x86_64 installations). Only libraries are installed by
      default.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>
     <literal>extraBuildCommands</literal>
    </term>
    <listitem>
     <para>
      Additional commands to be executed for finalizing the directory
      structure.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>
     <literal>extraBuildCommandsMulti</literal>
    </term>
    <listitem>
     <para>
      Like <literal>extraBuildCommands</literal>, but executed only on multilib
      architectures.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>
     <literal>extraOutputsToInstall</literal>
    </term>
    <listitem>
     <para>
      Additional derivation outputs to be linked for both target and
      multi-architecture packages.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>
     <literal>extraInstallCommands</literal>
    </term>
    <listitem>
     <para>
      Additional commands to be executed for finalizing the derivation with
      runner script.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>
     <literal>runScript</literal>
    </term>
    <listitem>
     <para>
      A command that would be executed inside the sandbox and passed all the
      command line arguments. It defaults to <literal>bash</literal>.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>

  <para>
   One can create a simple environment using a <literal>shell.nix</literal>
   like that:
  </para>

<programlisting><![CDATA[
{ pkgs ? import <nixpkgs> {} }:

(pkgs.buildFHSUserEnv {
  name = "simple-x11-env";
  targetPkgs = pkgs: (with pkgs;
    [ udev
      alsaLib
    ]) ++ (with pkgs.xorg;
    [ libX11
      libXcursor
      libXrandr
    ]);
  multiPkgs = pkgs: (with pkgs;
    [ udev
      alsaLib
    ]);
  runScript = "bash";
}).env
]]></programlisting>

  <para>
   Running <literal>nix-shell</literal> would then drop you into a shell with
   these libraries and binaries available. You can use this to run
   closed-source applications which expect FHS structure without hassles:
   simply change <literal>runScript</literal> to the application path, e.g.
   <filename>./bin/start.sh</filename> -- relative paths are supported.
  </para>
 </section>
 <xi:include href="shell.section.xml" />
 <section xml:id="sec-pkgs-dockerTools">
  <title>pkgs.dockerTools</title>

  <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/moby/moby/blob/master/image/spec/v1.2.md#docker-image-specification-v120">
   Docker Image Specification v1.2.0 </link>. Docker itself is not used to
   perform any of the operations done by these functions.
  </para>

  <warning>
   <para>
    The <varname>dockerTools</varname> API is unstable and may be subject to
    backwards-incompatible changes in the future.
   </para>
  </warning>

  <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>.
   </para>

   <para>
    The parameters of <varname>buildImage</varname> with relative example
    values are described below:
   </para>

   <example xml:id='ex-dockerTools-buildImage'>
    <title>Docker build</title>
<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}
    mkdir -p /data
  '';

  config = { <co xml:id='ex-dockerTools-buildImage-8' />
    Cmd = [ "/bin/redis-server" ];
    WorkingDir = "/data";
    Volumes = {
      "/data" = {};
    };
  };
}
</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.
   </para>

   <calloutlist>
    <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>.
     </para>
    </callout>
    <callout arearefs='ex-dockerTools-buildImage-2'>
     <para>
      <varname>tag</varname> specifies the tag of the resulting image. By
      default it's <literal>null</literal>, which indicates that the nix output
      hash will be used as tag.
     </para>
    </callout>
    <callout arearefs='ex-dockerTools-buildImage-3'>
     <para>
      <varname>fromImage</varname> is the repository tarball containing the
      base image. It must <