mirror of
https://github.com/NixOS/nixpkgs.git
synced 2024-11-26 17:03:01 +00:00
nixpkgs/manual: address review comments
Mostly taken from requested changes exactly as recommended.
This commit is contained in:
parent
498a242bf4
commit
d7b62cb601
@ -6,8 +6,8 @@
|
||||
|
||||
<para>
|
||||
When using Nix, you will frequently need to download source code
|
||||
and other file from the internet. Nixpkgs comes with a few helper
|
||||
functions that allow you to fetch fixed-output derivations in
|
||||
and other files from the internet. Nixpkgs comes with a few helper
|
||||
functions that allow you to fetch fixed-output derivations in a
|
||||
structured way.
|
||||
</para>
|
||||
|
||||
@ -48,7 +48,11 @@ stdenv.mkDerivation {
|
||||
|
||||
<para>
|
||||
<function>fetchpatch</function> works very similarly to
|
||||
<function>fetchurl</function> with the same arguments expected.
|
||||
<function>fetchurl</function> with the same arguments expected. It
|
||||
expects patch files as a source and and performs normalization on
|
||||
them before computing the checksum. For example it will remove
|
||||
comments or other unstable parts that are sometimes added by
|
||||
version control systems and can change over time.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -80,6 +84,9 @@ stdenv.mkDerivation {
|
||||
<para>
|
||||
Used with Git. Expects <literal>url</literal> to a Git repo,
|
||||
<literal>rev</literal>, and <literal>sha256</literal>.
|
||||
<literal>rev</literal> in this case can be full the git commit
|
||||
id (SHA1 hash) or a tag name like
|
||||
<literal>refs/tags/v1.0</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -141,9 +148,10 @@ stdenv.mkDerivation {
|
||||
GitHub HTML page as
|
||||
<literal>owner</literal>/<literal>repo</literal>.
|
||||
<literal>rev</literal> corresponds to the Git commit hash or
|
||||
tag that will be downloaded from Git. Finally,
|
||||
<literal>sha256</literal>. Again, other hash algorithms are
|
||||
also available but <literal>sha256</literal> is currently
|
||||
tag (e.g <literal>v1.0</literal>) that will be downloaded from
|
||||
Git. Finally, <literal>sha256</literal> corresponds to the
|
||||
hash of the extracted directory. Again, other hash algorithms
|
||||
are also available but <literal>sha256</literal> is currently
|
||||
preferred.
|
||||
</para>
|
||||
</listitem>
|
||||
|
@ -5,10 +5,10 @@
|
||||
<title>Trivial builders</title>
|
||||
|
||||
<para>
|
||||
There are a couple of functions provide in Nixpkgs that help with
|
||||
building derivations. The most important one,
|
||||
Nixpkgs provides a couple of functions that help with building
|
||||
derivations. The most important one,
|
||||
<function>stdenv.mkDerivation</function>, has already been
|
||||
documented above. These wrap
|
||||
documented above. The following functions wrap
|
||||
<function>stdenv.mkDerivation</function>, making it easier to use
|
||||
in certain cases.
|
||||
</para>
|
||||
@ -22,14 +22,42 @@
|
||||
<para>
|
||||
This takes three arguments, <literal>name</literal>,
|
||||
<literal>env</literal>, and <literal>buildCommand</literal>.
|
||||
<literal>name</literal> is just the name that Nix will use to
|
||||
refer to the derivation. <literal>env</literal> is an attribute
|
||||
set specifying environment variables that will be set for this
|
||||
derivation. <literal>buildCommand</literal> specifies the
|
||||
commands that will be run to create this derivation. Note that
|
||||
you will need to create <literal>$out</literal> for Nix to
|
||||
register the command as successful.
|
||||
</para>
|
||||
<literal>name</literal> is just the name that Nix will append
|
||||
to the store path in the same way that
|
||||
<literal>stdenv.mkDerivation</literal> uses its
|
||||
<literal>name</literal> attribute. <literal>env</literal> is an
|
||||
attribute set specifying environment variables that will be set
|
||||
for this derivation. These attributes are then passed to the
|
||||
wrapped <literal>stdenv.mkDerivation</literal>.
|
||||
<literal>buildCommand</literal> specifies the commands that
|
||||
will be run to create this derivation. Note that you will need
|
||||
to create <literal>$out</literal> for Nix to register the
|
||||
command as successful.
|
||||
</para>
|
||||
<para>
|
||||
An example of using <literal>runCommand</literal> is provided
|
||||
below.
|
||||
</para>
|
||||
<programlisting>
|
||||
(import <nixpkgs> {}).runCommand "my-example" {} ''
|
||||
echo My example command is running
|
||||
|
||||
mkdir $out
|
||||
|
||||
echo I can write data to the Nix store > $out/message
|
||||
|
||||
echo I can also run basic commands like:
|
||||
|
||||
echo ls
|
||||
ls
|
||||
|
||||
echo whoami
|
||||
whoami
|
||||
|
||||
echo date
|
||||
date
|
||||
''
|
||||
</programlisting>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
@ -47,19 +75,30 @@
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<literal>writeTextFile</literal>
|
||||
<literal>writeTextFile</literal>, <literal>writeText</literal>,
|
||||
<literal>writeTextDir</literal>, <literal>writeScript</literal>,
|
||||
<literal>writeScriptBin</literal>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This writes <literal>text</literal> to the Nix store. This is
|
||||
useful for creating scripts from Nix expressions. This takes an
|
||||
attribute set and expects two arguments,
|
||||
<literal>name</literal> and <literal>text</literal>.
|
||||
<literal>name</literal> corresponds to the name used in the Nix
|
||||
store path. <literal>text</literal> will be the contents of the
|
||||
file. You can also set <literal>executable</literal> to true to
|
||||
make this file have the executable bit set.
|
||||
</para>
|
||||
These functions write <literal>text</literal> to the Nix store.
|
||||
This is useful for creating scripts from Nix expressions.
|
||||
<literal>writeTextFile</literal> takes an attribute set and
|
||||
expects two arguments, <literal>name</literal> and
|
||||
<literal>text</literal>. <literal>name</literal> corresponds to
|
||||
the name used in the Nix store path. <literal>text</literal>
|
||||
will be the contents of the file. You can also set
|
||||
<literal>executable</literal> to true to make this file have
|
||||
the executable bit set.
|
||||
</para>
|
||||
<para>
|
||||
Many more commands wrap <literal>writeTextFile</literal>
|
||||
including <literal>writeText</literal>,
|
||||
<literal>writeTextDir</literal>,
|
||||
<literal>writeScript</literal>, and
|
||||
<literal>writeScriptBin</literal>. These are convenience
|
||||
functions over <literal>writeTextFile</literal>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
@ -75,7 +114,7 @@
|
||||
<literal>name</literal> is the name used in the Nix store path
|
||||
for the created derivation. <literal>paths</literal> is a list of
|
||||
paths that will be symlinked. These paths can be to Nix store
|
||||
derivations or any other directory.
|
||||
derivations or any other subdirectory contained within.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
@ -2207,7 +2207,8 @@ addEnvHooks "$hostOffset" myBashFunction
|
||||
This setup hook moves any installed documentation to the
|
||||
<literal>/share</literal> subdirectory directory. This includes
|
||||
the man, doc and info directories. This is needed for legacy
|
||||
programs that do not know use the share subdirectory.
|
||||
programs that do not know how to use the
|
||||
<literal>share</literal> subdirectory.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2219,7 +2220,7 @@ addEnvHooks "$hostOffset" myBashFunction
|
||||
<para>
|
||||
This setup hook compresses any man pages that have been
|
||||
installed. The compression is done using the gzip program. This
|
||||
helps to reduce installed size of packages.
|
||||
helps to reduce the installed size of packages.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2230,9 +2231,9 @@ addEnvHooks "$hostOffset" myBashFunction
|
||||
<listitem>
|
||||
<para>
|
||||
This runs the strip command on installed binaries and
|
||||
libraries. This removed things like debug symbols when they are
|
||||
not needed. This also helps to reduce installed size of
|
||||
packages.
|
||||
libraries. This removes unnecessary information like debug
|
||||
symbols when they are not needed. This also helps to reduce the
|
||||
installed size of packages.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2244,10 +2245,11 @@ addEnvHooks "$hostOffset" myBashFunction
|
||||
<para>
|
||||
This setup hook patches installed scripts to use the full path
|
||||
to the shebang interpreter. A shebang interpreter is the first
|
||||
commented line of a script telling the operating system
|
||||
what to use to run this script. In Nix, we want an exact path
|
||||
to that interpreter to be used. This often replcaes
|
||||
<literal>/bin/sh</literal> with a path in the Nix store.
|
||||
commented line of a script telling the operating system which
|
||||
program will run the script (e.g <literal>#!/bin/bash</literal>). In
|
||||
Nix, we want an exact path to that interpreter to be used. This
|
||||
often replaces <literal>/bin/sh</literal> with a path in the
|
||||
Nix store.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2260,7 +2262,7 @@ addEnvHooks "$hostOffset" myBashFunction
|
||||
This verifies that no references are left from the install
|
||||
binaries to the directory used to build those binaries. This
|
||||
ensures that the binaries do not need things outside the Nix
|
||||
store. This currently Linux only.
|
||||
store. This is currently supported in Linux only.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2425,9 +2427,9 @@ addEnvHooks "$hostOffset" myBashFunction
|
||||
|
||||
<para>
|
||||
Here are some more packages that provide a setup hook. Since the
|
||||
mechanism is modular, this probably isn't an exhaustive list. Then
|
||||
again, since the mechanism is only to be used as a last resort, it
|
||||
might be.
|
||||
list of hooks is extensible, this is not an exhaustive list the
|
||||
mechanism is only to be used as a last resort, it might cover most
|
||||
uses.
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
|
Loading…
Reference in New Issue
Block a user