[bug#47824] [PATCH 0/3] Happy hacking in the Spring 2021 LGJ

[Leo Prikler]

Hi Ludo,

Am Mittwoch, den 05.05.2021, 16:16 +0200 schrieb Ludovic Courtès:
> Hi Leo,
> 
> On a cursory look, all three patches LGTM.
> 
> One nit:
> 
> > +                   "exec "
> > +                   (assoc-ref inputs "guile-runtime")
> > +                   "/bin/guile " args)))
> 
> [...]
> 
> >         ("guile" ,guile-3.0)
> >         ("pkg-config" ,pkg-config)
> >         ("texinfo" ,texinfo)))
> > -    (propagated-inputs
> > -     `(("guile-sdl2" ,guile3.0-sdl2)))
> > +    (inputs
> > +     `(("guile-sdl2" ,guile3.0-sdl2)
> > +       ("guile-runtime" ,guile-3.0)))
> 
> I think it’s best to not play trick with labels, and to always use
> the
> package name as the label (to facilitate migration on the day where
> we
> get rid of labels, who knows…).
> 
> A common pattern for the case above is to provide “guile” both as
> native
> input and input, and to write:
> 
>   (assoc-ref (or native-inputs inputs) "guile")
What I'm doing here is the exact opposite.  I don't want the
omnipresent native-input guile to shadow the guile I use as input, so I
assign a "unique" label to the input guile to refer to it.  As a neat
side effect, this label allows me to construct GUILE_LOAD_PATH more
easily.

We already have a number of issues related to the "native-input as
input" thing, "which" returning the wrong binary, and so on, and I
didn't want to add another one on top.  The code I wrote certainly
looks and feels ugly, but I don't see any other way with what Guix
currently provides.  Maybe for the next c-u merge we can do proper
separation of inputs and native-inputs, hopefully using that to clean
up some of our recipes.  

Regards,
Leo