forked from lix-project/lix
remove separate meta-section, add architecture diagram
the diagram is a first approximation and only covers that same section. of course there is much more going on, and other features should at some point also be illustrated. we also have to think about presentation format and technicalities behind it. the manual has to render to `man`, but we may want something more refined for web view.
This commit is contained in:
parent
34ea74c9ec
commit
7598126391
|
@ -16,8 +16,7 @@
|
||||||
- [Environment Variables](installation/env-variables.md)
|
- [Environment Variables](installation/env-variables.md)
|
||||||
- [Upgrading Nix](installation/upgrading.md)
|
- [Upgrading Nix](installation/upgrading.md)
|
||||||
- [Design and Data Model](design/design.md)
|
- [Design and Data Model](design/design.md)
|
||||||
- [Overview](design/overview.md)
|
- [Store](design/store/store.md)
|
||||||
- [The Store Layer](design/store/store.md)
|
|
||||||
- [Store Objects](design/store/objects.md)
|
- [Store Objects](design/store/objects.md)
|
||||||
- [Store Paths](design/store/paths.md)
|
- [Store Paths](design/store/paths.md)
|
||||||
- [Nix Archives](design/store/nar.md)
|
- [Nix Archives](design/store/nar.md)
|
||||||
|
|
|
@ -1,6 +1,41 @@
|
||||||
# Design and Data Model
|
# Design and Data Model
|
||||||
|
|
||||||
Most of the manual is about how to use Nix.
|
|
||||||
This chapter is about the technical principles behind Nix.
|
This chapter is about the technical principles behind Nix.
|
||||||
|
|
||||||
It describes each architectural layer and its components in its own section, starting at the bottom with the store layer, then working its way up to the user-facing components described in the rest of the manual.
|
## Architecture
|
||||||
|
|
||||||
|
Nix consists of hierarchical [layers](https://en.m.wikipedia.org/wiki/Multitier_architecture#Layers).
|
||||||
|
|
||||||
|
```
|
||||||
|
[ commmand line interface ]
|
||||||
|
|
|
||||||
|
| evaluates
|
||||||
|
V
|
||||||
|
[ configuration language ]
|
||||||
|
|
|
||||||
|
| evaluates to
|
||||||
|
|
|
||||||
|
reference V build
|
||||||
|
[ build inputs ] --> [ build plans ] --> [ build results ]
|
||||||
|
\ | /
|
||||||
|
\ | persisted to /
|
||||||
|
\ V /
|
||||||
|
[ store ]
|
||||||
|
```
|
||||||
|
|
||||||
|
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 programming](https://en.m.wikipedia.org/wiki/Purely_functional_programming) language.
|
||||||
|
It is used to compose expressions which ultimately evaluate to self-contained *build steps*, 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 plans, data, and references between them.
|
||||||
|
It can also execute *build instructions*, captured in the build plans, to produce new data.
|
||||||
|
|
||||||
|
|
|
@ -1,20 +0,0 @@
|
||||||
# Overview
|
|
||||||
|
|
||||||
Nix consists of layers that operate fairly independently.
|
|
||||||
|
|
||||||
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 programming](https://en.m.wikipedia.org/wiki/Purely_functional_programming) language.
|
|
||||||
It is used to compose expressions which ultimately evaluate to self-contained *build steps*, 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 plans, data, and references between them.
|
|
||||||
It can also execute *build instructions*, captured in the build plans, to produce new data.
|
|
||||||
|
|
|
@ -1,4 +1,4 @@
|
||||||
# Nix Store
|
# Store
|
||||||
|
|
||||||
A Nix store is a collection of *store objects* referred to by *store paths*.
|
A Nix store is a collection of *store objects* referred to by *store paths*.
|
||||||
Every store also has a "store directory path", which is a path prefix used for various purposes.
|
Every store also has a "store directory path", which is a path prefix used for various purposes.
|
||||||
|
|
Loading…
Reference in a new issue