alioth/nixpkgs
3
0
Fork 0
forked from mirrors/nixpkgs
Code Releases Activity

Merge pull request #271797 from bzm3r/master

Browse source 
doc: diagram explaining what it means for a dependency to be propagated
This commit is contained in:
Silvan Mosberger 2023-12-21 17:14:30 +01:00 committed by GitHub
parent 347b18efff b37adfc009
commit 59a6f908b5
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 40 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

44
doc/stdenv/stdenv.chapter.md
View file

@ -261,14 +261,50 @@ For more complex cases, like libraries linked into an executable which is then e
As described in the Nix manual, almost any `*.drv` store path in a derivation’s attribute set will induce a dependency on that derivation. `mkDerivation`, however, takes a few attributes intended to include all the dependencies of a package. This is done both for structure and consistency, but also so that certain other setup can take place. For example, certain dependencies need their bin directories added to the `PATH`. That is built-in, but other setup is done via a pluggable mechanism that works in conjunction with these dependency attributes. See [](#ssec-setup-hooks) for details.
Dependencies can be broken down along three axes: their host and target platforms relative to the new derivation’s, and whether they are propagated. The platform distinctions are motivated by cross compilation; see [](#chap-cross) for exactly what each platform means. [^footnote-stdenv-ignored-build-platform] But even if one is not cross compiling, the platforms imply whether or not the dependency is needed at run-time or build-time, a concept that makes perfect sense outside of cross compilation. By default, the run-time/build-time distinction is just a hint for mental clarity, but with `strictDeps` set it is mostly enforced even in the native case.
Dependencies can be broken down along these axes: their host and target platforms relative to the new derivation’s. The platform distinctions are motivated by cross compilation; see [](#chap-cross) for exactly what each platform means. [^footnote-stdenv-ignored-build-platform] But even if one is not cross compiling, the platforms imply whether a dependency is needed at run-time or build-time.
The extension of `PATH` with dependencies, alluded to above, proceeds according to the relative platforms alone. The process is carried out only for dependencies whose host platform matches the new derivation’s build platform i.e. dependencies which run on the platform where the new derivation will be built. [^footnote-stdenv-native-dependencies-in-path] For each dependency \<dep\> of those dependencies, `dep/bin`, if present, is added to the `PATH` environment variable.
A dependency is said to be **propagated** when some of its other-transitive (non-immediate) downstream dependencies also need it as an immediate dependency.
[^footnote-stdenv-propagated-dependencies]
### Dependency propagation {#ssec-stdenv-dependencies-propagated}
It is important to note that dependencies are not necessarily propagated as the same sort of dependency that they were before, but rather as the corresponding sort so that the platform rules still line up. To determine the exact rules for dependency propagation, we start by assigning to each dependency a couple of ternary numbers (`-1` for `build`, `0` for `host`, and `1` for `target`) representing its [dependency type](#possible-dependency-types), which captures how its host and target platforms are each "offset" from the depending derivation’s host and target platforms. The following table summarize the different combinations that can be obtained:
Propagated dependencies are made available to all downstream dependencies.
This is particularly useful for interpreted languages, where all transitive dependencies have to be present in the same environment.
Therefore it is used for the Python infrastructure in Nixpkgs.
:::{.note}
Propagated dependencies should be used with care, because they obscure the actual build inputs of dependent derivations and cause side effects through setup hooks.
This can lead to conflicting dependencies that cannot easily be resolved.
:::
:::{.example}
# A propagated dependency
```nix
with import <nixpkgs> {};
let
bar = stdenv.mkDerivation {
name = "bar";
dontUnpack = true;
# `hello` is also made available to dependents, such as `foo`
propagatedBuildInputs = [ hello ];
postInstall = "mkdir $out";
};
foo = stdenv.mkDerivation {
name = "foo";
dontUnpack = true;
# `bar` is a direct dependency, which implicitly includes the propagated `hello`
buildInputs = [ bar ];
# The `hello` binary is available!
postInstall = "hello > $out";
};
in
foo
```
:::
Dependency propagation takes cross compilation into account, meaning that dependencies that cross platform boundaries are properly adjusted.
To determine the exact rules for dependency propagation, we start by assigning to each dependency a couple of ternary numbers (`-1` for `build`, `0` for `host`, and `1` for `target`) representing its [dependency type](#possible-dependency-types), which captures how its host and target platforms are each "offset" from the depending derivation’s host and target platforms. The following table summarize the different combinations that can be obtained:
| `host → target` | attribute name | offset |
| ------------------- | ------------------- | -------- |