diff options
| -rw-r--r-- | doc/manual/src/SUMMARY.md.in | 1 | ||||
| -rw-r--r-- | doc/manual/src/architecture/store/drvs/drvs.md | 59 |
2 files changed, 0 insertions, 60 deletions
diff --git a/doc/manual/src/SUMMARY.md.in b/doc/manual/src/SUMMARY.md.in index f356bd07d..5e2d26bf7 100644 --- a/doc/manual/src/SUMMARY.md.in +++ b/doc/manual/src/SUMMARY.md.in @@ -19,7 +19,6 @@ - [Store](architecture/store/store.md) - [Store Object](architecture/store/objects.md) - [Store Path](architecture/store/paths.md) - - [Derivation](architecture/store/drvs/drvs.md) - [Package Management](package-management/package-management.md) - [Basic Package Management](package-management/basic-package-mgmt.md) - [Profiles](package-management/profiles.md) diff --git a/doc/manual/src/architecture/store/drvs/drvs.md b/doc/manual/src/architecture/store/drvs/drvs.md deleted file mode 100644 index 5f374357d..000000000 --- a/doc/manual/src/architecture/store/drvs/drvs.md +++ /dev/null @@ -1,59 +0,0 @@ -# Derivation - -Derivations are recipes to create store objects. - -Derivations are the heart of Nix. -Other system (like Git or IPFS) also store and transfer immutable data, but they don't concern themselves with *how* that data was created. -This is where Nix comes in. - -Derivations produce data by running arbitrary commands, like Make or Ninja rules. -Unlike those systems, derivations do not produce arbitrary files, but only specific store objects. -They cannot modify the store in any way, other than creating those store objects. -This rigid specification of what they do is what allows Nix's caching to be so simple and yet robust. - -Based on the above, we can conceptually break derivations down into 3 parts: - -1. What command will be run? - -2. What existing store objects are needed as inputs? - -3. What store objects will be produced as outputs? - -## What command will be run? - -The original core of Nix was very simple about this, in the mold of traditional Unix. -Commands consist of 3 parts: - -1. Path to executable - -2. Arguments (Except for `argv[0]`, which is taken from the path in the usual way) - -3. Environment variables. - -## What existing store objects are needed as inputs? - -The previous sub-section begs the question "how can we be sure the path to the executable points to what we think it does?" -It's a good questions! - -## What store objects will be produced as outputs? - -## Extra extensions - -### `__structuredAttrs` - -Historically speaking, most users of Nix made GNU Bash with a script the command run, regardless of what they were doing. -Bash variable are automatically created from env vars, but bash also supports array and string-keyed map variables in addition to string variables. -People also usually create derivations using language which also support these richer data types. -It was thus desired a way to get this data from the language "planning" the derivation to language to bash, the language evaluated at "run time". - -`__structuredAttrs` does this by smuggling inside the core derivation format a map of named richer data. -At run time, this becomes two things: - -1. A JSON file containing that map. -2. A bash script setting those variables. - -The bash command can be passed a script which will "source" that Nix-created bash script, setting those variables with the richer data. -The outer script can then do whatever it likes with those richer variables as input. - -However, since derivations can already contain arbitary input sources, the vast majority of `__structuredAttrs` can be handled by upper layers. -We might consider implementing `__structuredAttrs` in higher layers in the future, and simplifying the store layer. |