blob: e8d87f8aeef8c082bbe28f7ccab379801bc2cf22 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
# Architecture
This chapter describes how Nix works.
It should help users understand why Nix behaves as it does, and it should help developers understand how to modify Nix and how to write similar tools.
## Overview
Nix consists of hierarchical [layers](https://en.m.wikipedia.org/wiki/Multitier_architecture#Layers).
```
[ commmand line interface ]--------+
| |
| evaluates | manages
V |
[ configuration language ] |
| |
+-------------------------------|---------------------V-----------+
| store | evaluates to |
| .............................V............................... |
| : build plan : |
| : referenced by builds : |
| : [ build input ] --> [ build task ] --> [ build result ] : |
| :...........................................................: |
+-----------------------------------------------------------------+
```
At the top is the *command line interface*, translating from invocations of Nix executables to interactions with the underlying layers.
Below that is the *Nix language*, a [purely functional](https://en.m.wikipedia.org/wiki/Purely_functional_programming) configuration language.
It is used to compose expressions which ultimately evaluate to self-contained *build plans*, made up *build tasks* used to derive *build results* from referenced *build inputs*.
::: {.note}
The Nix language itself does not have a notion of *packages* or *configurations*.
As far as we are concerned here, the inputs and results of a derivation are just data.
In practice this amounts to a set of files in a file system.
:::
The command line and Nix language are what users interact with most.
Underlying everything is the *Nix store*, a mechanism to keep track of build tasks, data, and references between them.
It can also execute *build instructions*, captured in the build tasks, to produce new data.
|
