forked from lix-project/lix
manual: build action -> build task
after discussing this with multiple people, I'm convinced that "build task" is more precise: a derivation is not an action, but inert until it is built. also it's easier to pronounce. proposal: use "build task" for the generic concept "description of how to derive new files from the contents of existing files". then it will be easier to distinguish what we mean by "derivation" (a specific data structure and Nix language value type) and "store derivation" (a serialisation of a derivation into a file in the Nix store).
This commit is contained in:
parent
499e99d099
commit
f7ab93b068
6 changed files with 9 additions and 9 deletions
|
@ -8,6 +8,6 @@
|
|||
|
||||
# Description
|
||||
|
||||
The Nix daemon is necessary in multi-user Nix installations. It performs
|
||||
build actions and other operations on the Nix store on behalf of
|
||||
The Nix daemon is necessary in multi-user Nix installations. It runs
|
||||
build tasks and other operations on the Nix store on behalf of
|
||||
unprivileged users.
|
||||
|
|
|
@ -71,7 +71,7 @@ paths. Realisation is a somewhat overloaded term:
|
|||
outputs are already valid, in which case we are done
|
||||
immediately. Otherwise, there may be [substitutes](../glossary.md)
|
||||
that produce the outputs (e.g., by downloading them). Finally, the
|
||||
outputs can be produced by performing the build action described
|
||||
outputs can be produced by running the build task described
|
||||
by the derivation.
|
||||
|
||||
- If the store path is not a derivation, realisation ensures that the
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
# Glossary
|
||||
|
||||
- [derivation]{#gloss-derivation}\
|
||||
A description of a build action. The result of a derivation is a
|
||||
A description of a build task. The result of a derivation is a
|
||||
store object. Derivations are typically specified in Nix expressions
|
||||
using the [`derivation` primitive](language/derivations.md). These are
|
||||
translated into low-level *store derivations* (implicitly by
|
||||
|
@ -53,8 +53,8 @@
|
|||
A file that is an immediate child of the Nix store directory. These
|
||||
can be regular files, but also entire directory trees. Store objects
|
||||
can be sources (objects copied from outside of the store),
|
||||
derivation outputs (objects produced by running a build action), or
|
||||
derivations (files describing a build action).
|
||||
derivation outputs (objects produced by running a build task), or
|
||||
derivations (files describing a build task).
|
||||
|
||||
- [input-addressed store object]{#gloss-input-addressed-store-object}\
|
||||
A store object produced by building a
|
||||
|
|
|
@ -104,7 +104,7 @@ a currently running program.
|
|||
|
||||
Packages are built from _Nix expressions_, which is a simple
|
||||
functional language. A Nix expression describes everything that goes
|
||||
into a package build action (a “derivation”): other packages, sources,
|
||||
into a package build task (a “derivation”): other packages, sources,
|
||||
the build script, environment variables for the build script, etc.
|
||||
Nix tries very hard to ensure that Nix expressions are
|
||||
_deterministic_: building a Nix expression twice should yield the same
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
# Derivations
|
||||
|
||||
The most important built-in function is `derivation`, which is used to
|
||||
describe a single derivation (a build action). It takes as input a set,
|
||||
describe a single derivation (a build task). It takes as input a set,
|
||||
the attributes of which specify the inputs of the build.
|
||||
|
||||
- There must be an attribute named [`system`]{#attr-system} whose value must be a
|
||||
|
|
|
@ -11,7 +11,7 @@ R""(
|
|||
# Description
|
||||
|
||||
This command runs the Nix daemon, which is a required component in
|
||||
multi-user Nix installations. It performs build actions and other
|
||||
multi-user Nix installations. It runs build tasks and other
|
||||
operations on the Nix store on behalf of non-root users. Usually you
|
||||
don't run the daemon directly; instead it's managed by a service
|
||||
management framework such as `systemd`.
|
||||
|
|
Loading…
Reference in a new issue