You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
33
+
22
34
-[store derivation]{#gloss-store-derivation}
23
35
24
36
A single build task.
@@ -88,6 +100,12 @@
88
100
89
101
[store]: #gloss-store
90
102
103
+
-[Nix instance]{#gloss-nix-instance}
104
+
<!-- ambiguous -->
105
+
1. An installation of Nix, which includes the presence of a [store], and the Nix package manager which operates on that store.
106
+
A local Nix installation and a [remote builder](@docroot@/advanced-topics/distributed-builds.md) are two examples of Nix instances.
107
+
2. A running Nix process, such as the `nix` command.
108
+
91
109
-[binary cache]{#gloss-binary-cache}
92
110
93
111
A *binary cache* is a Nix store which uses a different format: its
@@ -220,7 +238,7 @@
220
238
directly or indirectly “reachable” from that store path; that is,
221
239
it’s the closure of the path under the *references* relation. For
222
240
a package, the closure of its derivation is equivalent to the
223
-
build-time dependencies, while the closure of its output path is
241
+
build-time dependencies, while the closure of its [output path] is
224
242
equivalent to its runtime dependencies. For correct deployment it
225
243
is necessary to deploy whole closures, since otherwise at runtime
226
244
files could be missing. The command `nix-store --query --requisites ` prints out
@@ -78,7 +80,7 @@ type DerivingPath = ConstantPath | OutputPath;
78
80
```
79
81
80
82
Deriving paths are necessary because, in general and particularly for [content-addressing derivations][content-addressing derivation], the [store path] of an [output] is not known in advance.
81
-
We can use an output deriving path to refer to such an out, instead of the store path which we do not yet know.
83
+
We can use an output deriving path to refer to such an output, instead of the store path which we do not yet know.
82
84
83
85
[deriving path]: #deriving-path
84
86
[validity]: @docroot@/glossary.md#gloss-validity
@@ -89,25 +91,26 @@ A derivation is constructed from the parts documented in the following subsectio
89
91
90
92
### Inputs {#inputs}
91
93
92
-
The inputs are a set of [deriving paths][deriving path], refering to all store objects needed in order to perform this build step.
94
+
The inputs are a set of [deriving paths][deriving path], referring to all store objects needed in order to perform this build step.
93
95
94
96
The [process creation fields] will presumably include many [store paths][store path]:
95
97
96
98
- The path to the executable normally starts with a store path
97
99
- The arguments and environment variables likely contain many other store paths.
98
100
99
-
But rather than somehow scanning all the other fields for inputs, Nix requires that all inputs be explicitly collected in the inputs field. It is instead the responsibility of the creator of a derivation (e.g. the evaluator) to ensure that every store object referenced in another field (e.g. referenced by store path) is included in this inputs field.
101
+
But rather than somehow scanning all the other fields for inputs, Nix requires that all inputs be explicitly collected in the inputs field. It is instead the responsibility of the creator of a derivation (e.g. the evaluator) to ensure that every store object referenced in another field (e.g. referenced by store path) is included in this inputs field.
100
102
101
103
### System {#system}
102
104
103
105
The system type on which the [`builder`](#attr-builder) executable is meant to be run.
104
106
105
-
A necessary condition for Nix to schedule a given derivation on some Nix instance is for the "system" of that derivation to match that instance's [`system` configuration option].
107
+
A necessary condition for Nix to schedule a given derivation on some [Nix instance] is for the "system" of that derivation to match that instance's [`system` configuration option] or [`extra-platforms` configuration option].
106
108
107
109
By putting the `system` in each derivation, Nix allows *heterogenous* build plans, where not all steps can be run on the same machine or same sort of machine.
108
110
Nix can schedule builds such that it automatically builds on other platforms by [forwarding build requests](@docroot@/advanced-topics/distributed-builds.md) to other Nix instances.
Copy file name to clipboardExpand all lines: doc/manual/source/store/derivation/outputs/content-address.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ Given the method, the output's name (computed from the derivation name and outpu
12
12
13
13
## Fixed-output content-addressing {#fixed}
14
14
15
-
In this case the content-address of the *fixed* in advanced by the derivation itself.
15
+
In this case the contentaddress of the *fixed* in advanced by the derivation itself.
16
16
In other words, when the derivation has finished [building](@docroot@/store/building.md), and the provisional output' content-address is computed as part of the process to turn it into a *bona fide* store object, the calculated content address must much that given in the derivation, or the build of that derivation will be deemed a failure.
17
17
18
18
The output spec for an output with a fixed content addresses additionally contains:
@@ -159,7 +159,7 @@ A *determinstic* content-addressing derivation should produce outputs with the s
159
159
160
160
### Floating versus Fixed
161
161
162
-
While the destinction between content- and input-addressing is one of *mechanism*, the distinction between fixed and floating content addression is more one of *policy*.
162
+
While the distinction between content- and input-addressing is one of *mechanism*, the distinction between fixed and floating content addressing is more one of *policy*.
163
163
A fixed output that passes its content address check is just like a floating output.
164
164
It is only in the potential for that check to fail that they are different.
Copy file name to clipboardExpand all lines: doc/manual/source/store/derivation/outputs/input-address.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@
3
3
[input addressing]: #input-addressing
4
4
5
5
"Input addressing" means the address the store object by the *way it was made* rather than *what it is*.
6
-
That is to say, an input-addressed output's store path is a function not of the output itself, but the derivation that produced it.
6
+
That is to say, an input-addressed output's store path is a function not of the output itself, but of the derivation that produced it.
7
7
Even if two store paths have the same contents, if they are produced in different ways, and one is input-addressed, then they will have different store paths, and thus guaranteed to not be the same store object.
Copy file name to clipboardExpand all lines: doc/manual/source/store/store-object/content-address.md
+10-10Lines changed: 10 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,7 +28,7 @@ With all currently-supported store object content-addressing methods, the file s
28
28
29
29
### References
30
30
31
-
#### References to other store object#### References to other store objectss
31
+
#### References to other store objects
32
32
33
33
With all currently supported store object content addressing methods,
34
34
other objects are referred to by their regular (string-encoded-) [store paths][Store Path].
@@ -44,28 +44,28 @@ Self-references however cannot be referred to by their path, because we are in t
44
44
> which is computationally infeasible.
45
45
> As far as we know, this is equivalent to finding a hash collision.
46
46
47
-
Instead we have a "has selfreference" boolean, which end up affecting the digest:
48
-
In all currently-supported store object content-addressing methods, when hashing the file system object data, any occurence of store objects own store path in the digested data is replaced with a [sentinal value](https://en.wikipedia.org/wiki/Sentinel_value).
47
+
Instead we have a "has self-reference" boolean, which ends up affecting the digest:
48
+
In all currently-supported store object content-addressing methods, when hashing the file system object data, any occurence of store object's own store path in the digested data is replaced with a [sentinel value](https://en.wikipedia.org/wiki/Sentinel_value).
49
49
The hashes of these modified input streams are used instead.
50
50
51
-
When validating the content-address of a store object after the fact, the above process works as written.
51
+
When validating the contentaddress of a store object after the fact, the above process works as written.
52
52
However, when first creating the store object we don't know the store object's store path, as explained just above.
53
53
We therefore, strictly speaking, do not know what value we will be replacing with the sentinental value in the inputs to hash functions.
54
-
What instead happens is that the provisional store object --- the data from which we wish to create a store object --- is paired with a provisional "scratch" store path (that presumably was choosen when the data was created).
55
-
That provisional store path is instead what is replaced with the sentinal value, rather than the final store object which we do not yet know.
54
+
What instead happens is that the provisional store object --- the data from which we wish to create a store object --- is paired with a provisional "scratch" store path (that presumably was chosen when the data was created).
55
+
That provisional store path is instead what is replaced with the sentinel value, rather than the final store object which we do not yet know.
56
56
57
57
> **Design note**
58
58
>
59
59
> It is an informal property of content-addressed store objects that the choice of provisional store path should not matter.
60
60
> In other words, if a provisional store object is prepared in the same way except for the choice of provision store path, the provisional data need not be identical.
61
-
> But, after the sentinal value is substituted in place of each provisional store object's provision store path, the final so-normalized data *should* be identifical.
61
+
> But, after the sentinel value is substituted in place of each provisional store object's provision store path, the final so-normalized data *should* be identical.
62
62
>
63
63
> If, conversely, the data after this normalization process is still different, we'll compute a different content-address.
64
64
> The method of preparing the provisional self-referenced data has *failed* to be deterministic in the sense of not *leaking* the choice of provisional store path --- a choice which is supposed to be arbitrary --- into the final store object.
65
65
>
66
66
> This property is informal because at this stage, we are just described store objects, which have no formal notion of their origin.
67
67
> Without such a formal notion, there is nothing to formally accuse of being insufficiently deterministic.
68
-
> Later in this chapter, when we cover [derivations](@docroot@/store/derivation/index.md), we will have a chance to make this a formal property, not of content-addressed store objects themselves, but of derivations that *produce* content-addressed store objects.
68
+
> Where we cover [derivations](@docroot@/store/derivation/index.md), we will have a chance to make this a formal property, not of content-addressed store objects themselves, but of derivations that *produce* content-addressed store objects.
69
69
70
70
### Name and Store Directory
71
71
@@ -88,7 +88,7 @@ References are not supported: store objects with flat hashing *and* references c
88
88
89
89
This also uses the corresponding [Flat](../file-system-object/content-address.md#serial-flat) method of file system object content addressing.
90
90
91
-
References to other store objects are supported, but selfreferences are not.
91
+
References to other store objects are supported, but self-references are not.
92
92
93
93
This is the only store-object content-addressing method that is not named identically with a corresponding file system object method.
94
94
It is somewhat obscure, mainly used for "drv files"
@@ -99,7 +99,7 @@ Prefer another method if possible.
99
99
100
100
This uses the corresponding [Nix Archive](../file-system-object/content-address.md#serial-nix-archive) method of file system object content addressing.
101
101
102
-
References (to other store objects and selfreferences alike) are supported so long as the hash algorithm is SHA-256, but not (neither kind) otherwise.
102
+
References (to other store objects and self-references alike) are supported so long as the hash algorithm is SHA-256, but not (neither kind) otherwise.
0 commit comments