<simplesect> -> <section>
Pandoc silently ignores <simplesect>...
This commit is contained in:
Eelco Dolstra
parent
136fd55bb2
commit
ee05108472
|
|
@ -6,7 +6,7 @@
|
|||
|
||||
<title>Language Constructs</title>
|
||||
|
||||
<simplesect><title>Recursive sets</title>
|
||||
<section><title>Recursive sets</title>
|
||||
|
||||
<para>Recursive sets are just normal sets, but the attributes can
|
||||
refer to each other. For example,
|
||||
|
|
@ -38,10 +38,10 @@ does not terminate<footnote><para>Actually, Nix detects infinite
|
|||
recursion in this case and aborts (<quote>infinite recursion
|
||||
encountered</quote>).</para></footnote>.</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect xml:id="sect-let-expressions"><title>Let-expressions</title>
|
||||
<section xml:id="sect-let-expressions"><title>Let-expressions</title>
|
||||
|
||||
<para>A let-expression allows you to define local variables for an
|
||||
expression. For instance,
|
||||
|
|
@ -56,10 +56,10 @@ evaluates to <literal>"foobar"</literal>.
|
|||
|
||||
</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect><title>Inheriting attributes</title>
|
||||
<section><title>Inheriting attributes</title>
|
||||
|
||||
<para>When defining a set or in a let-expression it is often convenient to copy variables
|
||||
from the surrounding lexical scope (e.g., when you want to propagate
|
||||
|
|
@ -129,10 +129,10 @@ a = src-set.a; b = src-set.b; c = src-set.c;
|
|||
when used while defining local variables in a let-expression or
|
||||
while defining a set.</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect xml:id="ss-functions"><title>Functions</title>
|
||||
<section xml:id="ss-functions"><title>Functions</title>
|
||||
|
||||
<para>Functions have the following form:
|
||||
|
||||
|
|
@ -248,10 +248,10 @@ in concat { x = "foo"; y = "bar"; }</programlisting>
|
|||
|
||||
</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect><title>Conditionals</title>
|
||||
<section><title>Conditionals</title>
|
||||
|
||||
<para>Conditionals look like this:
|
||||
|
||||
|
|
@ -262,10 +262,10 @@ where <replaceable>e1</replaceable> is an expression that should
|
|||
evaluate to a Boolean value (<literal>true</literal> or
|
||||
<literal>false</literal>).</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect><title>Assertions</title>
|
||||
<section><title>Assertions</title>
|
||||
|
||||
<para>Assertions are generally used to check that certain requirements
|
||||
on or between features and dependencies hold. They look like this:
|
||||
|
|
@ -349,11 +349,11 @@ stdenv.mkDerivation {
|
|||
|
||||
</orderedlist>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
|
||||
<simplesect><title>With-expressions</title>
|
||||
<section><title>With-expressions</title>
|
||||
|
||||
<para>A <emphasis>with-expression</emphasis>,
|
||||
|
||||
|
|
@ -394,16 +394,16 @@ let a = 1; in let a = 2; in let a = 3; in let a = 4; in ...</programlisting>
|
|||
|
||||
</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect><title>Comments</title>
|
||||
<section><title>Comments</title>
|
||||
|
||||
<para>Comments can be single-line, started with a <literal>#</literal>
|
||||
character, or inline/multi-line, enclosed within <literal>/*
|
||||
... */</literal>.</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
<title>Values</title>
|
||||
|
||||
|
||||
<simplesect><title>Simple Values</title>
|
||||
<section><title>Simple Values</title>
|
||||
|
||||
<para>Nix has the following basic data types:
|
||||
|
||||
|
|
@ -193,10 +193,10 @@ stdenv.mkDerivation {
|
|||
|
||||
</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect><title>Lists</title>
|
||||
<section><title>Lists</title>
|
||||
|
||||
<para>Lists are formed by enclosing a whitespace-separated list of
|
||||
values between square brackets. For example,
|
||||
|
|
@ -217,10 +217,10 @@ function and the fifth being a set.</para>
|
|||
<para>Note that lists are only lazy in values, and they are strict in length.
|
||||
</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect><title>Sets</title>
|
||||
<section><title>Sets</title>
|
||||
|
||||
<para>Sets are really the core of the language, since ultimately the
|
||||
Nix language is all about creating derivations, which are really just
|
||||
|
|
@ -307,7 +307,7 @@ a form of object-oriented programming, for example.
|
|||
|
||||
</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ arbitrary Nix expressions, they may not get pre-built
|
|||
binaries.</para></note>
|
||||
|
||||
|
||||
<simplesect>
|
||||
<section>
|
||||
|
||||
<title>Setting up the build users</title>
|
||||
|
||||
|
|
@ -52,10 +52,10 @@ This creates 10 build users. There can never be more concurrent builds
|
|||
than the number of build users, so you may want to increase this if
|
||||
you expect to do many builds at the same time.</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect>
|
||||
<section>
|
||||
|
||||
<title>Running the daemon</title>
|
||||
|
||||
|
|
@ -78,10 +78,10 @@ export NIX_REMOTE=daemon</programlisting>
|
|||
|
||||
into the users’ login scripts.</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect>
|
||||
<section>
|
||||
|
||||
<title>Restricting access</title>
|
||||
|
||||
|
|
@ -101,7 +101,7 @@ cannot connect to the Unix domain socket
|
|||
<filename>/nix/var/nix/daemon-socket/socket</filename>, so they cannot
|
||||
perform Nix operations.</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ of the package’s build dependency graph). This enables many powerful
|
|||
features.</para>
|
||||
|
||||
|
||||
<simplesect><title>Multiple versions</title>
|
||||
<section><title>Multiple versions</title>
|
||||
|
||||
<para>You can have multiple versions or variants of a package
|
||||
installed at the same time. This is especially important when
|
||||
|
|
@ -39,10 +39,10 @@ uninstalling an application cannot break other applications, since
|
|||
these operations never “destructively” update or delete files that are
|
||||
used by other packages.</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect><title>Complete dependencies</title>
|
||||
<section><title>Complete dependencies</title>
|
||||
|
||||
<para>Nix helps you make sure that package dependency specifications
|
||||
are complete. In general, when you’re making a package for a package
|
||||
|
|
@ -68,10 +68,10 @@ scanning binaries for the hash parts of Nix store paths (such as
|
|||
<literal>r8vvq9kq…</literal>). This sounds risky, but it works
|
||||
extremely well.</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect><title>Multi-user support</title>
|
||||
<section><title>Multi-user support</title>
|
||||
|
||||
<para>Nix has multi-user support. This means that non-privileged
|
||||
users can securely install software. Each user can have a different
|
||||
|
|
@ -82,10 +82,10 @@ package won’t be built or downloaded a second time. At the same time,
|
|||
it is not possible for one user to inject a Trojan horse into a
|
||||
package that might be used by another user.</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect><title>Atomic upgrades and rollbacks</title>
|
||||
<section><title>Atomic upgrades and rollbacks</title>
|
||||
|
||||
<para>Since package management operations never overwrite packages in
|
||||
the Nix store but just add new versions in different paths, they are
|
||||
|
|
@ -103,10 +103,10 @@ $ nix-env --upgrade <replaceable>some-packages</replaceable>
|
|||
$ nix-env --rollback
|
||||
</screen>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect><title>Garbage collection</title>
|
||||
<section><title>Garbage collection</title>
|
||||
|
||||
<para>When you uninstall a package like this…
|
||||
|
||||
|
|
@ -126,10 +126,10 @@ $ nix-collect-garbage
|
|||
This deletes all packages that aren’t in use by any user profile or by
|
||||
a currently running program.</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect><title>Functional package language</title>
|
||||
<section><title>Functional package language</title>
|
||||
|
||||
<para>Packages are built from <emphasis>Nix expressions</emphasis>,
|
||||
which is a simple functional language. A Nix expression describes
|
||||
|
|
@ -145,10 +145,10 @@ function and call it any number of times with the appropriate
|
|||
arguments. Due to the hashing scheme, variants don’t conflict with
|
||||
each other in the Nix store.</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect><title>Transparent source/binary deployment</title>
|
||||
<section><title>Transparent source/binary deployment</title>
|
||||
|
||||
<para>Nix expressions generally describe how to build a package from
|
||||
source, so an installation action like
|
||||
|
|
@ -172,31 +172,31 @@ Nix would first check if the file
|
|||
if so, fetch the pre-built binary referenced from there; otherwise, it
|
||||
would fall back to building from source.</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<!--
|
||||
<simplesect><title>Binary patching</title>
|
||||
<section><title>Binary patching</title>
|
||||
|
||||
<para>In addition to downloading binaries automatically if they’re
|
||||
available, Nix can download binary deltas that patch an existing
|
||||
package in the Nix store into a new version. This speeds up
|
||||
upgrades.</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
-->
|
||||
|
||||
|
||||
<simplesect><title>Nix Packages collection</title>
|
||||
<section><title>Nix Packages collection</title>
|
||||
|
||||
<para>We provide a large set of Nix expressions containing hundreds of
|
||||
existing Unix packages, the <emphasis>Nix Packages
|
||||
collection</emphasis> (Nixpkgs).</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect><title>Managing build environments</title>
|
||||
<section><title>Managing build environments</title>
|
||||
|
||||
<para>Nix is extremely useful for developers as it makes it easy to
|
||||
automatically set up the build environment for a package. Given a
|
||||
|
|
@ -232,17 +232,17 @@ specifications, Nix makes an excellent basis for <a
|
|||
href="[%root%]hydra">a continuous build system</a>.</para>
|
||||
-->
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect><title>Portability</title>
|
||||
<section><title>Portability</title>
|
||||
|
||||
<para>Nix runs on Linux and macOS.</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect><title>NixOS</title>
|
||||
<section><title>NixOS</title>
|
||||
|
||||
<para>NixOS is a Linux distribution based on Nix. It uses Nix not
|
||||
just for package management but also to manage the system
|
||||
|
|
@ -253,16 +253,16 @@ earlier state. Also, users can install software without root
|
|||
privileges. For more information and downloads, see the <link
|
||||
xlink:href="http://nixos.org/">NixOS homepage</link>.</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
<simplesect><title>License</title>
|
||||
<section><title>License</title>
|
||||
|
||||
<para>Nix is released under the terms of the <link
|
||||
xlink:href="http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html">GNU
|
||||
LGPLv2.1 or (at your option) any later version</link>.</para>
|
||||
|
||||
</simplesect>
|
||||
</section>
|
||||
|
||||
|
||||
</chapter>
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
# Language Constructs
|
||||
|
||||
## Recursive sets
|
||||
|
||||
Recursive sets are just normal sets, but the attributes can refer to
|
||||
each other. For example,
|
||||
|
||||
|
|
@ -24,6 +26,8 @@ example,
|
|||
|
||||
does not terminate\[1\].
|
||||
|
||||
## Let-expressions
|
||||
|
||||
A let-expression allows you to define local variables for an expression.
|
||||
For instance,
|
||||
|
||||
|
|
@ -34,6 +38,8 @@ For instance,
|
|||
|
||||
evaluates to `"foobar"`.
|
||||
|
||||
## Inheriting attributes
|
||||
|
||||
When defining a set or in a let-expression it is often convenient to
|
||||
copy variables from the surrounding lexical scope (e.g., when you want
|
||||
to propagate attributes). This can be shortened using the `inherit`
|
||||
|
|
@ -95,6 +101,8 @@ is equivalent to
|
|||
when used while defining local variables in a let-expression or while
|
||||
defining a set.
|
||||
|
||||
## Functions
|
||||
|
||||
Functions have the following form:
|
||||
|
||||
pattern: body
|
||||
|
|
@ -187,6 +195,8 @@ you can bind them to an attribute, e.g.,
|
|||
let concat = { x, y }: x + y;
|
||||
in concat { x = "foo"; y = "bar"; }
|
||||
|
||||
## Conditionals
|
||||
|
||||
Conditionals look like this:
|
||||
|
||||
if e1 then e2 else e3
|
||||
|
|
@ -194,6 +204,8 @@ Conditionals look like this:
|
|||
where e1 is an expression that should evaluate to a Boolean value
|
||||
(`true` or `false`).
|
||||
|
||||
## Assertions
|
||||
|
||||
Assertions are generally used to check that certain requirements on or
|
||||
between features and dependencies hold. They look like this:
|
||||
|
||||
|
|
@ -257,6 +269,8 @@ The points of interest are:
|
|||
non-`null` value was passed. This prevents an unnecessary rebuild of
|
||||
Subversion if OpenSSL changes.
|
||||
|
||||
## With-expressions
|
||||
|
||||
A *with-expression*,
|
||||
|
||||
with e1; e2
|
||||
|
|
@ -285,6 +299,8 @@ establishes the same scope as
|
|||
|
||||
let a = 1; in let a = 2; in let a = 3; in let a = 4; in ...
|
||||
|
||||
## Comments
|
||||
|
||||
Comments can be single-line, started with a `#` character, or
|
||||
inline/multi-line, enclosed within `/*
|
||||
... */`.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
# Values
|
||||
|
||||
## Simple Values
|
||||
|
||||
Nix has the following basic data types:
|
||||
|
||||
- *Strings* can be written in three ways.
|
||||
|
|
@ -127,6 +129,8 @@ Nix has the following basic data types:
|
|||
|
||||
- The null value, denoted as `null`.
|
||||
|
||||
## Lists
|
||||
|
||||
Lists are formed by enclosing a whitespace-separated list of values
|
||||
between square brackets. For example,
|
||||
|
||||
|
|
@ -143,6 +147,8 @@ function and the fifth being a set.
|
|||
|
||||
Note that lists are only lazy in values, and they are strict in length.
|
||||
|
||||
## Sets
|
||||
|
||||
Sets are really the core of the language, since ultimately the Nix
|
||||
language is all about creating derivations, which are really just sets
|
||||
of attributes to be passed to build scripts.
|
||||
|
|
|
|||
|
|
@ -20,6 +20,8 @@ Nix store/database that performs the operation.
|
|||
> caches. So while unprivileged users may install packages from
|
||||
> arbitrary Nix expressions, they may not get pre-built binaries.
|
||||
|
||||
## Setting up the build users
|
||||
|
||||
The *build users* are the special UIDs under which builds are performed.
|
||||
They should all be members of the *build users group* `nixbld`. This
|
||||
group should have no other members. The build users should not be
|
||||
|
|
@ -35,6 +37,8 @@ This creates 10 build users. There can never be more concurrent builds
|
|||
than the number of build users, so you may want to increase this if you
|
||||
expect to do many builds at the same time.
|
||||
|
||||
## Running the daemon
|
||||
|
||||
The [Nix daemon](#sec-nix-daemon) should be started as follows (as
|
||||
`root`):
|
||||
|
||||
|
|
@ -50,6 +54,8 @@ should put a line like
|
|||
|
||||
into the users’ login scripts.
|
||||
|
||||
## Restricting access
|
||||
|
||||
To limit which users can perform Nix operations, you can use the
|
||||
permissions on the directory `/nix/var/nix/daemon-socket`. For instance,
|
||||
if you want to restrict the use of Nix to the members of a group called
|
||||
|
|
|
|||
Loading…
Reference in a new issue