<commit_before># 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 *derivations* — self-contained *build plans* to derive new data from referenced input data.

::: {.note}
The Nix language itself does not have a notion of *packages* or *configurations*.
As far as we are concerned here, the result of a derivation is 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 derivations, data, and references between them.
It can also *realise derivations*, that is, *execute build instructions* to produce new data.
It uses the file system as a persistence layer, and a database to keep track of references.

This chapter describes Nix starting at the bottom with the store layer, working its way up to the user-facing components described in the rest of the manual.

<commit_msg>only use generic build system terminology<commit_after># 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 plans*, 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.
It uses the file system as a persistence layer, and a database to keep track of references.

This chapter describes Nix starting at the bottom with the store layer, working its way up to the user-facing components described in the rest of the manual.


{'fraction_non_alphanumeric': 0.05109765329295988, 'fraction_numerical': 0.0, 'mean_word_length': 4.720779220779221, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4718271', 'n_tokens_mistral': 651, 'n_tokens_neox': 622, 'n_words': 396}