nixos/nix
1
1
Fork 0
mirror of https://github.com/NixOS/nix.git synced 2025-11-19 16:59:35 +01:00
Code Activity

Apply suggestions from code review

Browse source 
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
This commit is contained in:
John Ericson 2025-02-09 19:10:21 -05:00 • committed by GitHub
parent 094d352847
commit 298d199b89
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 22 additions and 16 deletions
Download patch file Download diff file Expand all files Collapse all files

38
doc/manual/source/store/drv.md
View file

@ -56,10 +56,16 @@ In pseudo code:
```typescript ```typescript
type OutputName = String; type OutputName = String;
type ConstantPath = { path: StorePath; } type ConstantPath = {
type OutputPath = { drvPath: StorePath; output: OutputName; } path: StorePath;
};
type DerivingPath = ConstantPath | OutputPath type OutputPath = {
drvPath: StorePath;
output: OutputName;
};
type DerivingPath = ConstantPath | OutputPath;
``` ```
Deriving paths are necessary because, in general and particularly for [content-addressed derivations][content-addressed derivation], the [store path] of an [output] is not known in advance. Deriving paths are necessary because, in general and particularly for [content-addressed derivations][content-addressed derivation], the [store path] of an [output] is not known in advance.
@ -76,9 +82,9 @@ A derivation is constructed from the parts documented in the following subsectio
The inputs are a set of [deriving paths][deriving path], refering to all store objects needed in order to perform this build step. The inputs are a set of [deriving paths][deriving path], refering to all store objects needed in order to perform this build step.
The information needed for the `execve` system call will presumably include many [store paths][store path]: The [process creation fields] will presumably include many [store paths][store path]:
- The path to the executable is almost surely starts with a store path - The path to the executable normally starts with a store path
- The arguments and environment variables likely contain many other store paths. - The arguments and environment variables likely contain many other store paths.
But just as we stored the references contained in the file data separately for store objects, so we store the set of inputs separately from the builder, arguments, and environment variables. But just as we stored the references contained in the file data separately for store objects, so we store the set of inputs separately from the builder, arguments, and environment variables.
@ -91,9 +97,9 @@ Outputs are assigned names, and also consistent of other information based on th
Output names can be any string which is also a valid [store path] name. Output names can be any string which is also a valid [store path] name.
The store path of the output store object (also called an [output path] for short), has a name based on the derivation name and the output name. The store path of the output store object (also called an [output path] for short), has a name based on the derivation name and the output name.
Most outputs' store paths have name `drvMame + '-' + outputName`. In the general case, store paths have name `derivationName + "-" + outputName`.
However, an output named "out" has a store path with name `drvName`. However, an output named "out" has a store path with name is just the derivation name.
This is to allow derivations with a single output to avoid a superfluous `-<outputName>` in their single output's name when no disambiguation is needed. This is to allow derivations with a single output to avoid a superfluous `"-${outputName}"` in their single output's name when no disambiguation is needed.
> **Example** > **Example**
> >
@ -107,8 +113,8 @@ This is to allow derivations with a single output to avoid a superfluous `-<outp
### Process creation fields {#process-creation-fields} ### Process creation fields {#process-creation-fields}
These are the three fields which describe out to spawn the process which (along with any of its own child processes) will perform the build. These are the three fields which describe how to spawn the process which (along with any of its own child processes) will perform the build.
As state in the derivation introduction, this is everything needed for an `execve` system call. You may note that this has everything needed for an `execve` system call.
#### Builder {#builder} #### Builder {#builder}
@ -119,23 +125,23 @@ This is the path to an executable that will perform the build and produce the [o
Command-line arguments to be passed to the [`builder`](#builder) executable. Command-line arguments to be passed to the [`builder`](#builder) executable.
Note that these are the arguments after the first argument. Note that these are the arguments after the first argument.
The first argument, `argv[0]`, is the "base name" of the `builder`, as per the usual convention on Unix. The first argument passed to the `builder` will be the value of `builder`, as per the usual convention on Unix.
See [Wikipedia](https://en.wikipedia.org/w/index.php?title=Argv) for details. See [Wikipedia](https://en.wikipedia.org/wiki/Argv) for details.
#### Environment Variables {#env} #### Environment Variables {#env}
Environment variables which will be passed to the [builder](#builder) executable. Environment variables which will be passed to the [builder](#builder) executable.
#### Placeholders ### Placeholders
Placeholders are opaque values used within the [process creation fields] to [store objects] for which we don't yet know [store path]s. Placeholders are opaque values used within the [process creation fields] to [store objects] for which we don't yet know [store path]s.
The are strings in the form `/<hash>` that are embedded anywhere within the strings of those fields. They are strings in the form `/<hash>` that are embedded anywhere within the strings of those fields, and we are [considering](https://github.com/NixOS/nix/issues/12361) to add store-path-like placeholders.
> **Note** > **Note**
> >
> Output Deriving Path exist to solve the same problem as placeholders --- that is, referring to store objects for which we don't yet know a store path. > Output Deriving Path exist to solve the same problem as placeholders --- that is, referring to store objects for which we don't yet know a store path.
> They also have a string syntax, [descibed in the encoding section](#deriving-path-encoding). > They also have a string syntax with `^`, [described in the encoding section](#deriving-path-encoding).
> We could use that syntax instead of `/<hash>` for placeholders, but its human-legibility would cuse problems. > We could use that syntax instead of `/<hash>` for placeholders, but its human-legibility would cause problems.
There are two types of placeholder, corresponding to the two cases where this problem arises: There are two types of placeholder, corresponding to the two cases where this problem arises: