Re: Rethinking propagated inputs?

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi,

Am Dienstag, den 07.09.2021, 12:01 -0700 schrieb Sarah Morgensen:
> [...]
> 
> 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.
I think if you wanted to build go-foo locally, you should go with just
`guix environment go-foo' anyway.  For the source code, you might be
interested in `guix build --source'.

> 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)))
This is basically a weaker linked-inputs, because linked-inputs could
be sanitized while these propagated inputs could not.

> 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.
Again same as introducing a new field, but also changing semantics for
everything in the tree.  I think having "propagated-inputs" mean what
it means is fine.  If we do find that we're lacking a field with
certain semantics, we should add that or change existing fields in
backwards-compatible ways.

> 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.
Your example should have propagated-inputs.  I'm not sure what benefit
there is to this solution that isn't given by adding a field, except
that it can't be sanitized.  Now that I think about it, this seems to
be a different syntax to 1.

> 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...
W.r.t. relying on the packager to know that, we could document such use
cases in the manual (similar to how they are documented currently) and
we still have a review process to fall back on.

Regards