Maxim Cournoyer <maxim.courno...@gmail.com> writes: > It seems the original issue pointed at was somewhat misguided; is there > still something to be fixed about propagated inputs? It seems the > discussion has moved toward handling propagated inputs for the use of > pkg-config. > > What are the current problems with it, and what would the advantages be > to move away from the status quo? If there aren't clear benefits, I'd > prefer the status quo, abstaining from the added complexity.
As I mentioned up-thread: Sarah Morgensen <iskar...@mgsn.dev> writes: >> Does anyone have an idea how we should handle propagations for the sake >> of pkg-config? Perhaps we could add "linked-inputs", which are added >> when building packages and environments when not using --ad-hoc, but >> not when union-building profiles. WDYT? > > I know nothing about pkg-config, but such an input would help > simplify things for Go (and I think for Rust) since many inputs need to > be propagated only at build-time. In Go(/Rust), the dependency packages' output contains only source, and for a package to build it must have the source of all its transitive inputs available. However, IMO it doesn't make sense to automatically install these in a profile when installing that package. If you're installing a source-only package, you likely don't want all the transitive dependencies automatically installed--what if you're just inspecting the source, or want to try building it with different dependencies? If you want all the build dependencies as well, you would just do guix environment go-foo --ad-hoc go-foo like you would do for other Guix packages. In the context of this discussion, I can think of three types of solution: 1. Add a modifier like #:profile? (defaulting to #f) to propagated-inputs entries (propagated-inputs `(("foo" #:profile? #t))) 2. Rename "propagated-inputs" to e.g. "profile-propagated-inputs", and then introduce a new "propagated-inputs", which only propagates into the inputs of dependents, and not into built profiles. 3. Introduce a way to prevent an input from propagating anything into the current package/profile (inputs `(("foo" #:propagate? #f))) and then provide CLI options (transformations) to control this. I think the first two are clear and make the packager consider exactly what they're going to propagate into user profiles. Of course, both also rely on the packager always knowing what should be propagated to a user's profile or not. The third option allows more control over that (and could be combined with one of the first two), but feels a bit rough to use... WDYT? -- Sarah