Re: Rethinking propagated inputs?

[iskarian]

Hi,

September 8, 2021 12:18 AM, "Liliana Marie Prikler" <liliana.prikler@gmail.com> 
wrote:

> 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'.

guix build --source doesn't capture any modifications made in the dependency 
package, such as
rewriting paths or other patching.

You're right, though, in that (for now) it's a rare use-case, and probably 
doesn't warrant the
added complexity and the extra field. It just feels... messy as it is now.

>> 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.

Good point. I included it because there seemed to be pushback on adding a field.

>> 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.

I agree; I should have stated this differently ("Add a new field"). The name is 
just bikeshedding.

>> 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.

Ah, I forgot to state that in this example, "foo" is the package with a 
propagated-inputs field,
and this is a dependent package (or a profile) which does not want "foo"'s 
propagated-inputs to be
propagated to it.

This way a packager has an "escape hatch" if something unwanted got propagated. 
Thinking about it
some more, though, in such a case it's more likely to want to disallow a 
specific package than a
whole set of propagated inputs. If such a feature would actually be useful 
(questionable), it's
probably better implemented differently than this (disallowed-inputs, perhaps, 
to mirror
disallowed-references)?

I hope I made some more sense this time!

--
Sarah