[bug#65062] [PATCH core-updates 1/1] packages: Specify output in input label when it's not "out".

[Hilton Chain via Guix-patches via <guix-patches@gnu.org>]

Hi Ludo,

On Sat, 09 Sep 2023 06:03:53 +0800,
Ludovic Courtès wrote:
>
> Hi,
>
> Hilton Chain <hako@ultrarare.space> skribis:
>
> >> Hilton Chain <hako@ultrarare.space> skribis:
> >>
> >> > * guix/packages.scm (add-input-label): Specify output when it's not "out".
> >>
> >> [...]
> >>
> >> > +         (list (string-append (package-name package) ":" output)
> >> > +               package
> >> > +               output)))
> >>
> >> The Grand Plan¹ is to eventually get rid of labels entirely (or almost:
> >> there’d still be input alists on the build side).  As such, I thought we
> >> shouldn’t worry too much about what the actual label is.  But perhaps
> >> you stumbled upon situations where this is a problem?  Could you
> >> describe them?
>
> [...]
>
> > My main concern is that currently modify-inputs, this-package-input
> > and this-package-native-input operate on input labels and there would
> > be duplicated labels if adding multiple outputs of a package.
> >
> > For modify-inputs, I think there's no approach to solve this without
> > also specifying labels in inputs.
>
> Yes, good point.
>
> Another, more radical approach, would be to change semantics, whereby
> (inputs (list p)) would mean that all the outputs of ‘p’, not just
> “out”, are taken as inputs.  That’d simplify inputs at the expense of
> precision, and (this-package-input NAME) would always be unambiguous.
>
> But maybe that’s too radical and uncertain.
>
> So all things considered, I guess you’re right and we should do what you
> propose.


Thank you!


> Minor issues:
>
> > --- a/guix/packages.scm
> > +++ b/guix/packages.scm
> > @@ -626,7 +626,13 @@ (define (add-input-label input)
> >      ((? package? package)
> >       (list (package-name package) package))
> >      (((? package? package) output)                ;XXX: ugly?
> > -     (list (package-name package) package output))
> > +     (if (string=? output "out")
> > +         ;; (package "out") => ("package" package "out")
> > +         (list (package-name package) package output)
> > +         ;; (package "output") => ("package:output" package "output")
> > +         (list (string-append (package-name package) ":" output)
> > +               package
> > +               output)))
>
> Rather write it as two separate clauses, without comments:
>
>   (((? package? package) "out")
>    …)
>   (((? package? package) output)
>    …)
>
> Could you also add a test case in ‘tests/packages.scm’ that would look
> up inputs by those labels?


I have thought about this patch again recently.


First of all, I didn't describe my own trouble clearly:

I wanted to put `this-package-input' into #$gcc:lib, but didn't know how.  Now I
understand that (ungexp (this-package-input "gcc") "lib") can be used and input
labels are not quite related...


And then I realised that there's too much extra work in package definitions for
the label change.


So, how about looking up inputs by specification (name + version + output), and
falling back to input labels?  I think this can address the issue regarding
multiple outputs and versions, while keeping compatible with existing behavior.

I'll send v2 for the change, with a different subject.  Though I haven't written
new tests for it, the existing (tests packages) passes when applied to master
and no package definition needs changing at least for building guix.


Thanks