mirror of
https://github.com/NixOS/nix.git
synced 2025-12-07 09:31:01 +01:00
Merge remote-tracking branch 'origin/2.30-maintenance' into sync-2.30.0
This commit is contained in:
Eelco Dolstra
commit
175406c313
284 changed files with 9123 additions and 4178 deletions
|
|
@ -52,6 +52,7 @@
|
|||
- [Tuning Cores and Jobs](advanced-topics/cores-vs-jobs.md)
|
||||
- [Verifying Build Reproducibility](advanced-topics/diff-hook.md)
|
||||
- [Using the `post-build-hook`](advanced-topics/post-build-hook.md)
|
||||
- [Evaluation profiler](advanced-topics/eval-profiler.md)
|
||||
- [Command Reference](command-ref/index.md)
|
||||
- [Common Options](command-ref/opt-common.md)
|
||||
- [Common Environment Variables](command-ref/env-common.md)
|
||||
|
|
@ -147,6 +148,7 @@
|
|||
- [Release 3.0.0 (2025-03-04)](release-notes-determinate/rl-3.0.0.md)
|
||||
- [Nix Release Notes](release-notes/index.md)
|
||||
{{#include ./SUMMARY-rl-next.md}}
|
||||
- [Release 2.30 (2025-07-07)](release-notes/rl-2.30.md)
|
||||
- [Release 2.29 (2025-05-14)](release-notes/rl-2.29.md)
|
||||
- [Release 2.28 (2025-04-02)](release-notes/rl-2.28.md)
|
||||
- [Release 2.27 (2025-03-03)](release-notes/rl-2.27.md)
|
||||
|
|
|
|||
33
doc/manual/source/advanced-topics/eval-profiler.md
Normal file
33
doc/manual/source/advanced-topics/eval-profiler.md
Normal file
|
|
@ -0,0 +1,33 @@
|
|||
# Using the `eval-profiler`
|
||||
|
||||
Nix evaluator supports [evaluation](@docroot@/language/evaluation.md)
|
||||
[profiling](<https://en.wikipedia.org/wiki/Profiling_(computer_programming)>)
|
||||
compatible with `flamegraph.pl`. The profiler samples the nix
|
||||
function call stack at regular intervals. It can be enabled with the
|
||||
[`eval-profiler`](@docroot@/command-ref/conf-file.md#conf-eval-profiler)
|
||||
setting:
|
||||
|
||||
```console
|
||||
$ nix-instantiate "<nixpkgs>" -A hello --eval-profiler flamegraph
|
||||
```
|
||||
|
||||
Stack sampling frequency and the output file path can be configured with
|
||||
[`eval-profile-file`](@docroot@/command-ref/conf-file.md#conf-eval-profile-file)
|
||||
and [`eval-profiler-frequency`](@docroot@/command-ref/conf-file.md#conf-eval-profiler-frequency).
|
||||
By default the collected profile is saved to `nix.profile` file in the current working directory.
|
||||
|
||||
The collected profile can be directly consumed by `flamegraph.pl`:
|
||||
|
||||
```console
|
||||
$ flamegraph.pl nix.profile > flamegraph.svg
|
||||
```
|
||||
|
||||
The line information in the profile contains the location of the [call
|
||||
site](https://en.wikipedia.org/wiki/Call_site) position and the name of the
|
||||
function being called (when available). For example:
|
||||
|
||||
```
|
||||
/nix/store/x9wnkly3k1gkq580m90jjn32q9f05q2v-source/pkgs/top-level/default.nix:167:5:primop import
|
||||
```
|
||||
|
||||
Here `import` primop is called at `/nix/store/x9wnkly3k1gkq580m90jjn32q9f05q2v-source/pkgs/top-level/default.nix:167:5`.
|
||||
|
|
@ -59,6 +59,11 @@ This command has the following operations:
|
|||
Download the Nix expressions of subscribed channels and create a new generation.
|
||||
Update all channels if none is specified, and only those included in *names* otherwise.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Downloaded channel contents are cached.
|
||||
> Use `--tarball-ttl` or the [`tarball-ttl` configuration option](@docroot@/command-ref/conf-file.md#conf-tarball-ttl) to change the validity period of cached downloads.
|
||||
|
||||
- `--list-generations`
|
||||
|
||||
Prints a list of all the current existing generations for the
|
||||
|
|
|
|||
|
|
@ -31,9 +31,22 @@
|
|||
|
||||
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.
|
||||
|
||||
- [derivation]{#gloss-derivation}
|
||||
|
||||
A derivation can be thought of as a [pure function](https://en.wikipedia.org/wiki/Pure_function) that produces new [store objects][store object] from existing store objects.
|
||||
|
||||
Derivations are implemented as [operating system processes that run in a sandbox](@docroot@/store/building.md#builder-execution).
|
||||
This sandbox by default only allows reading from store objects specified as inputs, and only allows writing to designated [outputs][output] to be [captured as store objects](@docroot@/store/building.md#processing-outputs).
|
||||
|
||||
A derivation is typically specified as a [derivation expression] in the [Nix language], and [instantiated][instantiate] to a [store derivation].
|
||||
There are multiple ways of obtaining store objects from store derivatons, collectively called [realisation][realise].
|
||||
|
||||
[derivation]: #gloss-derivation
|
||||
|
||||
- [store derivation]{#gloss-store-derivation}
|
||||
|
||||
A single build task.
|
||||
A [derivation] represented as a [store object].
|
||||
|
||||
See [Store Derivation](@docroot@/store/derivation/index.md#store-derivation) for details.
|
||||
|
||||
[store derivation]: #gloss-store-derivation
|
||||
|
|
@ -57,10 +70,7 @@
|
|||
|
||||
- [derivation expression]{#gloss-derivation-expression}
|
||||
|
||||
A description of a [store derivation] in the Nix language.
|
||||
The output(s) of a derivation are store objects.
|
||||
Derivations are typically specified in Nix expressions using the [`derivation` primitive](./language/derivations.md).
|
||||
These are translated into store layer *derivations* (implicitly by `nix-env` and `nix-build`, or explicitly by `nix-instantiate`).
|
||||
A description of a [store derivation] using the [`derivation` primitive](./language/derivations.md) in the [Nix language].
|
||||
|
||||
[derivation expression]: #gloss-derivation-expression
|
||||
|
||||
|
|
|
|||
|
|
@ -53,23 +53,13 @@ Derivations can declare some infrequently used optional attributes.
|
|||
|
||||
- [`__structuredAttrs`]{#adv-attr-structuredAttrs}\
|
||||
If the special attribute `__structuredAttrs` is set to `true`, the other derivation
|
||||
attributes are serialised into a file in JSON format. The environment variable
|
||||
`NIX_ATTRS_JSON_FILE` points to the exact location of that file both in a build
|
||||
and a [`nix-shell`](../command-ref/nix-shell.md). This obviates the need for
|
||||
[`passAsFile`](#adv-attr-passAsFile) since JSON files have no size restrictions,
|
||||
unlike process environments.
|
||||
attributes are serialised into a file in JSON format.
|
||||
|
||||
It also makes it possible to tweak derivation settings in a structured way; see
|
||||
[`outputChecks`](#adv-attr-outputChecks) for example.
|
||||
This obviates the need for [`passAsFile`](#adv-attr-passAsFile) since JSON files have no size restrictions, unlike process environments.
|
||||
It also makes it possible to tweak derivation settings in a structured way;
|
||||
see [`outputChecks`](#adv-attr-outputChecks) for example.
|
||||
|
||||
As a convenience to Bash builders,
|
||||
Nix writes a script that initialises shell variables
|
||||
corresponding to all attributes that are representable in Bash. The
|
||||
environment variable `NIX_ATTRS_SH_FILE` points to the exact
|
||||
location of the script, both in a build and a
|
||||
[`nix-shell`](../command-ref/nix-shell.md). This includes non-nested
|
||||
(associative) arrays. For example, the attribute `hardening.format = true`
|
||||
ends up as the Bash associative array element `${hardening[format]}`.
|
||||
See the [corresponding section in the derivation page](@docroot@/store/derivation/index.md#structured-attrs) for further details.
|
||||
|
||||
> **Warning**
|
||||
>
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Nix Language
|
||||
|
||||
The Nix language is designed for conveniently creating and composing *derivations* – precise descriptions of how contents of existing files are used to derive new files.
|
||||
The Nix language is designed for conveniently creating and composing [derivations](@docroot@/glossary.md#gloss-derivation) – precise descriptions of how contents of existing files are used to derive new files.
|
||||
|
||||
> **Tip**
|
||||
>
|
||||
|
|
|
|||
|
|
@ -196,7 +196,7 @@ All comparison operators are implemented in terms of `<`, and the following equi
|
|||
|
||||
## Logical implication
|
||||
|
||||
Equivalent to `!`*b1* `||` *b2*.
|
||||
Equivalent to `!`*b1* `||` *b2* (or `if` *b1* `then` *b2* `else true`)
|
||||
|
||||
[Logical implication]: #logical-implication
|
||||
|
||||
|
|
|
|||
|
|
@ -225,8 +225,8 @@ passed in first , e.g.,
|
|||
|
||||
```nix
|
||||
let add = { __functor = self: x: x + self.x; };
|
||||
inc = add // { x = 1; };
|
||||
in inc 1
|
||||
inc = add // { x = 1; }; # inc is { x = 1; __functor = (...) }
|
||||
in inc 1 # equivalent of `add.__functor add 1` i.e. `1 + self.x`
|
||||
```
|
||||
|
||||
evaluates to `2`. This can be used to attach metadata to a function
|
||||
|
|
|
|||
|
|
@ -85,3 +85,7 @@ is a JSON object with the following fields:
|
|||
|
||||
* `env`:
|
||||
The environment passed to the `builder`.
|
||||
|
||||
* `structuredAttrs`:
|
||||
[Strucutured Attributes](@docroot@/store/derivation/index.md#structured-attrs), only defined if the derivation contains them.
|
||||
Structured attributes are JSON, and thus embedded as-is.
|
||||
|
|
|
|||
|
|
@ -284,7 +284,7 @@
|
|||
|
||||
`<nix/fetchurl.nix>` is also known as the builtin derivation builder `builtin:fetchurl`. It's not to be confused with the evaluation-time function `builtins.fetchurl`, which was not affected by this issue.
|
||||
|
||||
# Contributors
|
||||
## Contributors
|
||||
|
||||
This release was made possible by the following 43 contributors:
|
||||
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@
|
|||
`<nix/fetchurl.nix>` is also known as the builtin derivation builder `builtin:fetchurl`. It's not to be confused with the evaluation-time function `builtins.fetchurl`, which was not affected by this issue.
|
||||
|
||||
|
||||
# Contributors
|
||||
## Contributors
|
||||
|
||||
This release was made possible by the following 58 contributors:
|
||||
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@
|
|||
|
||||
- Evaluation caching now works for dirty Git workdirs [#11992](https://github.com/NixOS/nix/pull/11992)
|
||||
|
||||
# Contributors
|
||||
## Contributors
|
||||
|
||||
This release was made possible by the following 45 contributors:
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@
|
|||
blake3-34P4p+iZXcbbyB1i4uoF7eWCGcZHjmaRn6Y7QdynLwU=
|
||||
```
|
||||
|
||||
# Contributors
|
||||
## Contributors
|
||||
|
||||
This release was made possible by the following 21 contributors:
|
||||
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ This completes the infrastructure overhaul for the [RFC 132](https://github.com/
|
|||
Although this change is not as critical, we figured it would be good to do this API change at the same time, also.
|
||||
Also note that we try to keep the C API compatible, but we decided to break this function because it was young and likely not in widespread use yet. This frees up time to make important progress on the rest of the C API.
|
||||
|
||||
# Contributors
|
||||
## Contributors
|
||||
|
||||
This earlier-than-usual release was made possible by the following 16 contributors:
|
||||
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ This fact is counterbalanced by the fact that most of those changes are bug fixe
|
|||
This in particular prevents parts of GCC 14's diagnostics from being improperly filtered away.
|
||||
|
||||
|
||||
# Contributors
|
||||
## Contributors
|
||||
|
||||
|
||||
This release was made possible by the following 40 contributors:
|
||||
|
|
|
|||
153
doc/manual/source/release-notes/rl-2.30.md
Normal file
153
doc/manual/source/release-notes/rl-2.30.md
Normal file
|
|
@ -0,0 +1,153 @@
|
|||
# Release 2.30.0 (2025-07-07)
|
||||
|
||||
## Backward-incompatible changes and deprecations
|
||||
|
||||
- [`build-dir`] no longer defaults to `$TMPDIR`
|
||||
|
||||
The directory in which temporary build directories are created no longer defaults
|
||||
to `TMPDIR` or `/tmp`, to avoid builders making their directories
|
||||
world-accessible. This behavior allowed escaping the build sandbox and can
|
||||
cause build impurities even when not used maliciously. We now default to `builds`
|
||||
in `NIX_STATE_DIR` (which is `/nix/var/nix/builds` in the default configuration).
|
||||
|
||||
- Deprecate manually making structured attrs using the `__json` attribute [#13220](https://github.com/NixOS/nix/pull/13220)
|
||||
|
||||
The proper way to create a derivation using [structured attrs] in the Nix language is by using `__structuredAttrs = true` with [`builtins.derivation`].
|
||||
However, by exploiting how structured attrs are implementated, it has also been possible to create them by setting the `__json` environment variable to a serialized JSON string.
|
||||
This sneaky alternative method is now deprecated, and may be disallowed in future versions of Nix.
|
||||
|
||||
[structured attrs]: @docroot@/language/advanced-attributes.md#adv-attr-structuredAttrs
|
||||
[`builtins.derivation`]: @docroot@/language/builtins.html#builtins-derivation
|
||||
|
||||
- Rename `nix profile install` to [`nix profile add`] [#13224](https://github.com/NixOS/nix/pull/13224)
|
||||
|
||||
The command `nix profile install` has been renamed to [`nix profile add`] (though the former is still available as an alias). This is because the verb "add" is a better antonym for the verb "remove" (i.e. `nix profile remove`). Nix also does not have install hooks or general behavior often associated with "installing".
|
||||
|
||||
## Performance improvements
|
||||
|
||||
This release has a number performance improvements, in particular:
|
||||
|
||||
- Reduce the size of value from 24 to 16 bytes [#13407](https://github.com/NixOS/nix/pull/13407)
|
||||
|
||||
This shaves off a very significant amount of memory used for evaluation (~20% percent reduction in maximum heap size and ~17% in total bytes).
|
||||
|
||||
## Features
|
||||
|
||||
- Add [stack sampling evaluation profiler] [#13220](https://github.com/NixOS/nix/pull/13220)
|
||||
|
||||
The Nix evaluator now supports [stack sampling evaluation profiling](@docroot@/advanced-topics/eval-profiler.md) via the [`--eval-profiler flamegraph`] setting.
|
||||
It outputs collapsed call stack information to the file specified by
|
||||
[`--eval-profile-file`] (`nix.profile` by default) in a format directly consumable
|
||||
by `flamegraph.pl` and compatible tools like [speedscope](https://speedscope.app/).
|
||||
Sampling frequency can be configured via [`--eval-profiler-frequency`] (99 Hz by default).
|
||||
|
||||
Unlike the existing [`--trace-function-calls`], this profiler includes the name of the function
|
||||
being called when it's available.
|
||||
|
||||
- [`nix repl`] prints which variables were loaded [#11406](https://github.com/NixOS/nix/pull/11406)
|
||||
|
||||
Instead of `Added <n> variables` it now prints the first 10 variables that were added to the global scope.
|
||||
|
||||
- `nix flake archive`: Add [`--no-check-sigs`] option [#13277](https://github.com/NixOS/nix/pull/13277)
|
||||
|
||||
This is useful when using [`nix flake archive`] with the destination set to a remote store.
|
||||
|
||||
- Emit warnings for IFDs with [`trace-import-from-derivation`] option [#13279](https://github.com/NixOS/nix/pull/13279)
|
||||
|
||||
While we have the setting [`allow-import-from-derivation`] to deny import-from-derivation (IFD), sometimes users would like to observe IFDs during CI processes to gradually phase out the idiom. The new setting `trace-import-from-derivation`, when set, logs a simple warning to the console.
|
||||
|
||||
- `json-log-path` setting [#13003](https://github.com/NixOS/nix/pull/13003)
|
||||
|
||||
New setting [`json-log-path`] that sends a copy of all Nix log messages (in JSON format) to a file or Unix domain socket.
|
||||
|
||||
- Non-flake inputs now contain a `sourceInfo` attribute [#13164](https://github.com/NixOS/nix/issues/13164) [#13170](https://github.com/NixOS/nix/pull/13170)
|
||||
|
||||
Flakes have always had a `sourceInfo` attribute which describes the source of the flake.
|
||||
The `sourceInfo.outPath` is often identical to the flake's `outPath`. However, it can differ when the flake is located in a subdirectory of its source.
|
||||
|
||||
Non-flake inputs (i.e. inputs with [`flake = false`]) can also be located at some path _within_ a wider source.
|
||||
This usually happens when defining a relative path input within the same source as the parent flake, e.g. `inputs.foo.url = ./some-file.nix`.
|
||||
Such relative inputs will now inherit their parent's `sourceInfo`.
|
||||
|
||||
This also means it is now possible to use `?dir=subdir` on non-flake inputs.
|
||||
|
||||
This iterates on the work done in 2.26 to improve relative path support ([#10089](https://github.com/NixOS/nix/pull/10089)),
|
||||
and resolves a regression introduced in 2.28 relating to nested relative path inputs ([#13164](https://github.com/NixOS/nix/issues/13164)).
|
||||
|
||||
## Miscellaneous changes
|
||||
|
||||
- [`builtins.sort`] uses PeekSort [#12623](https://github.com/NixOS/nix/pull/12623)
|
||||
|
||||
Previously it used libstdc++'s `std::stable_sort()`. However, that implementation is not reliable if the user-supplied comparison function is not a strict weak ordering.
|
||||
|
||||
- Revert incomplete closure mixed download and build feature [#77](https://github.com/NixOS/nix/issues/77) [#12628](https://github.com/NixOS/nix/issues/12628) [#13176](https://github.com/NixOS/nix/pull/13176)
|
||||
|
||||
Since Nix 1.3 ([commit `299141e`] in 2013) Nix has attempted to mix together upstream fresh builds and downstream substitutions when remote substuters contain an "incomplete closure" (have some store objects, but not the store objects they reference).
|
||||
This feature is now removed.
|
||||
|
||||
In the worst case, removing this feature could cause more building downstream, but it should not cause outright failures, since this is not happening for opaque store objects that we don't know how to build if we decide not to substitute.
|
||||
In practice, however, we doubt even more building is very likely to happen.
|
||||
Remote stores that are missing dependencies in arbitrary ways (e.g. corruption) don't seem to be very common.
|
||||
|
||||
On the contrary, when remote stores fail to implement the [closure property](@docroot@/store/store-object.md#closure-property), it is usually an *intentional* choice on the part of the remote store, because it wishes to serve as an "overlay" store over another store, such as `https://cache.nixos.org`.
|
||||
If an "incomplete closure" is encountered in that situation, the right fix is not to do some sort of "franken-building" as this feature implemented, but instead to make sure both substituters are enabled in the settings.
|
||||
|
||||
(In the future, we should make it easier for remote stores to indicate this to clients, to catch settings that won't work in general before a missing dependency is actually encountered.)
|
||||
|
||||
## Contributors
|
||||
|
||||
This release was made possible by the following 32 contributors:
|
||||
|
||||
- Cole Helbling [**(@cole-h)**](https://github.com/cole-h)
|
||||
- Eelco Dolstra [**(@edolstra)**](https://github.com/edolstra)
|
||||
- Egor Konovalov [**(@egorkonovalov)**](https://github.com/egorkonovalov)
|
||||
- Farid Zakaria [**(@fzakaria)**](https://github.com/fzakaria)
|
||||
- Graham Christensen [**(@grahamc)**](https://github.com/grahamc)
|
||||
- gustavderdrache [**(@gustavderdrache)**](https://github.com/gustavderdrache)
|
||||
- Gwenn Le Bihan [**(@gwennlbh)**](https://github.com/gwennlbh)
|
||||
- h0nIg [**(@h0nIg)**](https://github.com/h0nIg)
|
||||
- Jade Masker [**(@donottellmetonottellyou)**](https://github.com/donottellmetonottellyou)
|
||||
- jayeshv [**(@jayeshv)**](https://github.com/jayeshv)
|
||||
- Jeremy Fleischman [**(@jfly)**](https://github.com/jfly)
|
||||
- John Ericson [**(@Ericson2314)**](https://github.com/Ericson2314)
|
||||
- Jonas Chevalier [**(@zimbatm)**](https://github.com/zimbatm)
|
||||
- Jörg Thalheim [**(@Mic92)**](https://github.com/Mic92)
|
||||
- kstrafe [**(@kstrafe)**](https://github.com/kstrafe)
|
||||
- Luc Perkins [**(@lucperkins)**](https://github.com/lucperkins)
|
||||
- Matt Sturgeon [**(@MattSturgeon)**](https://github.com/MattSturgeon)
|
||||
- Nikita Krasnov [**(@synalice)**](https://github.com/synalice)
|
||||
- Peder Bergebakken Sundt [**(@pbsds)**](https://github.com/pbsds)
|
||||
- pennae [**(@pennae)**](https://github.com/pennae)
|
||||
- Philipp Otterbein
|
||||
- Pol Dellaiera [**(@drupol)**](https://github.com/drupol)
|
||||
- PopeRigby [**(@poperigby)**](https://github.com/poperigby)
|
||||
- Raito Bezarius
|
||||
- Robert Hensing [**(@roberth)**](https://github.com/roberth)
|
||||
- Samuli Thomasson [**(@SimSaladin)**](https://github.com/SimSaladin)
|
||||
- Sergei Zimmerman [**(@xokdvium)**](https://github.com/xokdvium)
|
||||
- Seth Flynn [**(@getchoo)**](https://github.com/getchoo)
|
||||
- Stefan Boca [**(@stefanboca)**](https://github.com/stefanboca)
|
||||
- tomberek [**(@tomberek)**](https://github.com/tomberek)
|
||||
- Tristan Ross [**(@RossComputerGuy)**](https://github.com/RossComputerGuy)
|
||||
- Valentin Gagarin [**(@fricklerhandwerk)**](https://github.com/fricklerhandwerk)
|
||||
- Vladimír Čunát [**(@vcunat)**](https://github.com/vcunat)
|
||||
- Wolfgang Walther [**(@wolfgangwalther)**](https://github.com/wolfgangwalther)
|
||||
|
||||
<!-- markdown links -->
|
||||
[stack sampling evaluation profiler]: @docroot@/advanced-topics/eval-profiler.md
|
||||
[`--eval-profiler`]: @docroot@/command-ref/conf-file.md#conf-eval-profiler
|
||||
[`--eval-profiler flamegraph`]: @docroot@/command-ref/conf-file.md#conf-eval-profiler
|
||||
[`--trace-function-calls`]: @docroot@/command-ref/conf-file.md#conf-trace-function-calls
|
||||
[`--eval-profile-file`]: @docroot@/command-ref/conf-file.md#conf-eval-profile-file
|
||||
[`--eval-profiler-frequency`]: @docroot@/command-ref/conf-file.md#conf-eval-profiler-frequency
|
||||
[`build-dir`]: @docroot@/command-ref/conf-file.md#conf-build-dir
|
||||
[`nix profile add`]: @docroot@/command-ref/new-cli/nix3-profile-add.md
|
||||
[`nix repl`]: @docroot@/command-ref/new-cli/nix3-repl.md
|
||||
[`nix flake archive`]: @docroot@/command-ref/new-cli/nix3-flake-archive.md
|
||||
[`json-log-path`]: @docroot@/command-ref/conf-file.md#conf-json-log-path
|
||||
[`trace-import-from-derivation`]: @docroot@/command-ref/conf-file.md#conf-trace-import-from-derivation
|
||||
[`allow-import-from-derivation`]: @docroot@/command-ref/conf-file.md#conf-allow-import-from-derivation
|
||||
[`builtins.sort`]: @docroot@/language/builtins.md#builtins-sort
|
||||
[`flake = false`]: @docroot@/command-ref/new-cli/nix3-flake.md?highlight=false#flake-inputs
|
||||
[`--no-check-sigs`]: @docroot@/command-ref/new-cli/nix3-flake-archive.md#opt-no-check-sigs
|
||||
[commit `299141e`]: https://github.com/NixOS/nix/commit/299141ecbd08bae17013226dbeae71e842b4fdd7
|
||||
|
|
@ -138,6 +138,17 @@ See [Wikipedia](https://en.wikipedia.org/wiki/Argv) for details.
|
|||
|
||||
Environment variables which will be passed to the [builder](#builder) executable.
|
||||
|
||||
#### Structured Attributes {#structured-attrs}
|
||||
|
||||
Nix also has special support for embedding JSON in the derivations.
|
||||
|
||||
The environment variable `NIX_ATTRS_JSON_FILE` points to the exact location of that file both in a build and a [`nix-shell`](@docroot@/command-ref/nix-shell.md).
|
||||
|
||||
As a convenience to Bash builders, Nix writes a script that initialises shell variables corresponding to all attributes that are representable in Bash.
|
||||
The environment variable `NIX_ATTRS_SH_FILE` points to the exact location of the script, both in a build and a [`nix-shell`](@docroot@/command-ref/nix-shell.md).
|
||||
This includes non-nested (associative) arrays.
|
||||
For example, the attribute `hardening.format = true` ends up as the Bash associative array element `${hardening[format]}`.
|
||||
|
||||
### Placeholders
|
||||
|
||||
Placeholders are opaque values used within the [process creation fields] to [store objects] for which we don't yet know [store path]s.
|
||||
|
|
@ -162,7 +173,7 @@ There are two types of placeholder, corresponding to the two cases where this pr
|
|||
|
||||
> **Explanation**
|
||||
>
|
||||
> In general, we need to realise [realise] a [store object] in order to be sure to have a store object for it.
|
||||
> In general, we need to [realise] a [store object] in order to be sure to have a store object for it.
|
||||
> But for these two cases this is either impossible or impractical:
|
||||
>
|
||||
> - In the output case this is impossible:
|
||||
|
|
@ -189,7 +200,7 @@ This ensures that there is a canonical [store path] used to refer to the derivat
|
|||
> **Note**
|
||||
>
|
||||
> Currently, the canonical encoding for every derivation is the "ATerm" format,
|
||||
> but this is subject to change for types derivations which are not yet stable.
|
||||
> but this is subject to change for the types of derivations which are not yet stable.
|
||||
|
||||
Regardless of the format used, when serializing a derivation to a store object, that store object will be content-addressed.
|
||||
|
||||
|
|
@ -282,7 +293,7 @@ type DerivingPath = ConstantPath | OutputPath;
|
|||
|
||||
Under this extended model, `DerivingPath`s are thus inductively built up from a root `ConstantPath`, wrapped with zero or more outer `OutputPath`s.
|
||||
|
||||
### Encoding {#deriving-path-encoding}
|
||||
### Encoding {#deriving-path-encoding-higher-order}
|
||||
|
||||
The encoding is adjusted in the natural way, encoding the `drv` field recursively using the same deriving path encoding.
|
||||
The result of this is that it is possible to have a chain of `^<output-name>` at the end of the final string, as opposed to just a single one.
|
||||
|
|
|
|||
|
|
@ -18,14 +18,14 @@ In particular, the edge corresponding to a reference is from the store object th
|
|||
References other than a self-reference must not form a cycle.
|
||||
The graph of references excluding self-references thus forms a [directed acyclic graph].
|
||||
|
||||
[directed acyclic graph]: @docroot@/glossary.md#gloss-directed acyclic graph
|
||||
[directed acyclic graph]: @docroot@/glossary.md#gloss-directed-acyclic-graph
|
||||
|
||||
We can take the [transitive closure] of the references graph, which any pair of store objects have an edge not if there is a single reference from the first to the second, but a path of one or more references from the first to the second.
|
||||
The *requisites* of a store object are all store objects reachable by paths of references which start with given store object's references.
|
||||
|
||||
[transitive closure]: https://en.wikipedia.org/wiki/Transitive_closure
|
||||
|
||||
We can also take the [transpose graph] ofthe references graph, where we reverse the orientation of all edges.
|
||||
We can also take the [transpose graph] of the references graph, where we reverse the orientation of all edges.
|
||||
The *referrers* of a store object are the store objects that reference it.
|
||||
|
||||
[transpose graph]: https://en.wikipedia.org/wiki/Transpose_graph
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue