Most of all however, I am not motivated to continue the PR, for the following reasons:
@roberth: requests concrete names are used rather than abstract symbols- my gut reaction: names are noise that ought to be used with great care, as they can introduce distinctions, or identifications, where none are necessary. At best, they help create a sense of familiarity but only if our assumptions about what is familiar to the reader are correct. (Note that as can be seen in multiple places within these notes, I myself am very guilty of making assumptions regarding readers.)
- as a quick example:
@roberth's suggested example for use as renaming confused me. Nativity does not matter for the concept of transitivity-interpreted-as-propagation.
- as a quick example:
- my gut reaction: names are noise that ought to be used with great care, as they can introduce distinctions, or identifications, where none are necessary. At best, they help create a sense of familiarity but only if our assumptions about what is familiar to the reader are correct. (Note that as can be seen in multiple places within these notes, I myself am very guilty of making assumptions regarding readers.)
@infinisilsuggests using a small code snippet to illustrate the manual sentence's intent, and then including a diagram as support for the snippet.- I liked this idea. Whenever possible, I prefer "algebra" to "pictures" (which have the same problem as names). But, apart from its aesthetic agreement with my gut, it also helped me realize a question which lurks below all of this:
Why do we need propagation at all? Why can I not explicitly list a dependency multiple times in buildInputs for a derivation that requires it? I say that this is explicit, because in terms of the notation that @infinsil provided: propagatedBuildInputs notationally hides that the shared dependency is a dependency for both upstream and downstream.
The manual does sort of provide an answer this this (but it is in a footnote which I had ignored at the time):
Footnote 3 Nix itself already takes a package’s transitive dependencies into account, but this propagation ensures nixpkgs-specific infrastructure like setup hooks also are run as if it were a propagated dependency
When is it necessary then, for such propagation hooks to run? Always? Never? (ans: its complicated) Are propagation hooks necessary for the shared dependency to be memoized and re-used across the dependency tree? (ans: no)
These are the points the manual should be addressing (in my humble opinion), because the question of what it means for a dependency to be propagated is extremely trivial: any simple code snippet will suffice (and there is (arguably) no need for a diagram). But once you make it notationally clear that propagation is not notationally explicit, the above questions begin to form.
Most important, is that @Ericson2314 effectively points out the above as depressingly unnecessary messiness:
I don't think I really like propagated deps because it is a "solution" with unclear effects (run env hooks downstream more....huh? what's that?) in response to various domain-specific situations that should probably each be written down explicitly rather than translated into this awkward nixpkgs jargon. (For example, see pkg-config's public vs private library dependencies. They explain it poorly but there is an actual domain-level concept there).
The point of the above is that in my opinion (as an inexperienced beginner), the real question lies in what is happening during propagation (which the manual barely touches on), and not what propagation means (which a code snippet will immediately make obvious as implicit/magical notation).