Re: Rethinking propagated inputs?

[Sarah Morgensen]

Maxim Cournoyer <maxim.cournoyer@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 <iskarian@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