glossary: re-introduce "derivation" #12994
Conversation
fricklerhandwerk
force-pushed
the
reword-derivation
branch
from
a5b1629 to
f3a37d4
Compare
|
@Ericson2314 interesting, I thought store derivations are a certain representation of the abstract notion of a derivation. Nothing says derivations are required to be store objects. |
|
The store derivation section just sends the reader to |
The "derivation" is one of the key concepts and captures the most distinctive aspect of Nix: that we work with a certain type data (linked files) in a certain manner (using pure functions). Here we finally arrange all the important pieces to show how they belong together, while referring to the respective reference documentation for details. This change also unbreaks downstream links to `//glossary#gloss-derivation`, which had been broken by removing the glossary entry
fricklerhandwerk
force-pushed
the
reword-derivation
branch
from
c8166b2 to
8db8371
Compare
| @@ -31,9 +31,22 @@ | |||
|
|
|||
| The industry term for storage and retrieval systems using [content addressing](#gloss-content-address). A Nix store also has [input addressing](#gloss-input-addressed-store-object), and metadata. | |||
|
|
|||
| - [derivation]{#gloss-derivation} | |||
|
|
|||
| A derivation can be thought of as a [pure function](https://en.wikipedia.org/wiki/Pure_function) that produces new [store objects][store object] from existing store objects. | |||
There was a problem hiding this comment.
This is not true because a function maps many possible arguments to results (many possible inputs) but a derivation has a specific set of inputs.
A derivation that depends on the outputs of another derivation is closer to being a function, because we don't know what those outputs are at the time of creating the derivation, but even this needs more explaining.
I think it would be better to say a derivation is a function application than a function. since it is applying a function-in-our-heads to some inputs.
| - [store derivation]{#gloss-store-derivation} | ||
|
|
||
| A single build task. | ||
| A [derivation] represented as a [store object]. | ||
|
|
||
| See [Store Derivation](@docroot@/store/derivation/index.md#store-derivation) for details. |
There was a problem hiding this comment.
This is not how "store derivation" is defined in that chapter. Rather the thing the glossary now calls "derivation" (the abstract concept) is called "store derivation".
We need to make things consistent. I would rather just always say "derivation" and drop the "store " part everywhere, but I am open to other options.
| Derivations are implemented as [operating system processes that run in a sandbox](@docroot@/store/building.md#builder-execution). | ||
| This sandbox by default only allows reading from store objects specified as inputs, and only allows writing to designated [outputs][output] to be [captured as store objects](@docroot@/store/building.md#processing-outputs). |
There was a problem hiding this comment.
I don't see why need this text here. These details can go in the chapter on derivations. The glossary entry is supposed to be an extremely short description that links to the chapter.
|
master...Ericson2314:nix:reword-derivation I tried putting some things here to start fixing this |
Motivation
The "derivation" is one of the key concepts and captures the most distinctive aspect of Nix:
that we work with a certain type data (linked files) in a certain manner (using pure functions).
Context
Here we finally arrange all the important pieces to show how they belong
together, while referring to the respective reference documentation for details.
This change also unbreaks downstream links to
//glossary#gloss-derivation,which had been broken by removing the glossary entry
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.