Most builtins are now generated from data too, with two exceptions: * Undocumented builtins, since supporting them would add complexity to the generator, the harms of the current implementation mostly don't apply, and the proper fix is to document them. * `derivation` is somewhat magic (it is a function, but defined in the code as a constant), so the current treatment of having it separately documented is kept (for now, at least). Since it is slightly easier to do and probably a good idea anyway, the builtin function registrations generated this way are now processed directly in code and don't go through global variables any more. Unfortunately, a slight breaking change is introduced because the order of the builtins' names in the symbol table changes. Hopefully, this will turn out to not matter in practice. Change-Id: I7b4379a93ae380b6524e41a916a21c5c6f70555e
783 B
783 B
name, args
| name | args | |
|---|---|---|
| storePath |
|
This function allows you to define a dependency on an already
existing store path. For example, the derivation attribute src = builtins.storePath /nix/store/f1d18v1y…-source causes the
derivation to depend on the specified path, which must exist or
be substitutable. Note that this differs from a plain path
(e.g. src = /nix/store/f1d18v1y…-source) in that the latter
causes the path to be copied again to the Nix store, resulting
in a new path (e.g. /nix/store/ld01dnzc…-source-source).
Not available in pure evaluation mode. Lix may change this, tracking issue: https://git.lix.systems/lix-project/lix/issues/402
See also builtins.fetchClosure.