[bug#49597] [PATCH core-updates 00/15] Ajust packages to label-less input style

["Ludovic Courtès" <ludo@gnu.org>]

Hello Maxime!

Maxime Devos <maximedevos@telenet.be> skribis:

> Ludovic Courtès schreef op vr 16-07-2021 om 17:50 [+0200]:
>> The rest is about removing reliance on input labels in build-side
>> code, primarily by changing:
>> 
>>   (string-append (assoc-ref inputs "LABEL") "FILE")
>> 
>> to one of:
>> 
>>   (search-input-file inputs "FILE")
>>   (search-input-directory inputs "FILE")
>> 
>> This change will help if we eventually remove input labels entirely
>> from the API (remember that input labels are now unnecessary in
>> package definitions but they’re still returned by ‘package-inputs’
>> and similar procedures).
>> 
>> The idea is that code should not rely on package names when looking
>> for files as this would prevent things such as
>> ‘--with-inputs=openmpi=mpich’ since the label in the original package
>> would be “openmpi” whereas it’d be “mpich” in the transformed package.
>> In this case (a kind of “virtual dependencies”), a better idiom is:
>> 
>>   (search-input-file inputs "lib/libmpi.so")
>> 
>> as this explicitly accommodates any implementation of that library.
>
> I would have expected that --with-inputs=x=y would turn the following:
>
> (package
>   [...]
>   (inputs `(("x" ,x))))
>
> into:
>
> (package
>   [...]
>   (inputs `(("x" ,y))))
>
> i.e., keep the label intact, but change the package value.

Yes, that’s what happens right now, even on ‘core-updates’.  So to be
clear, there’s no problem at this point.

There will be a problem when we remove input labels entirely from the
API.  At that point, the labels that build-side code will see (if we
keep them at all…) will necessarily be package names.  In the example
above, “x” would be replaced by “y”.

This series is one way to anticipate for this change (which would happen
at the earliest on the next ‘core-updates’ cycle, which could be six
months from now, maybe more).

[...]

> In the example you gave, both search-input-file and the original 'string-append'
> and 'assoc-ref' look convenient to me, though the latter more so than the other,
> and a third variant could be
>
>   #$(file-append (this-package-native-input "openmpi") "/lib/libmpi.so")
>
> which avoids 'string-append' and 'assoc-ref'.

Yes, but you’re still relying on the name, “openmpi”.

If I do:

  (package
    (inherit thing)
    (inputs `(("mpich" ,mpich)
              ,@(delete "openmpi" (package-inputs thing)))))

… then you have a problem: ‘this-package-input’ won’t find “openmpi”.
It’s a real, common use case.  That’s why we need to be careful about
the idioms we promote.

WDYT?

> (I prefer explicitely writing in the package definition in which input a file
> will be found, as a kind of documentation, though in this case it probably
> doesn't really matter.)

Yeah, I like that too.  OTOH, ‘search-input-file’ has the advantage that
it errors out if the file is not found, whereas

  (string-append (assoc-ref inputs "foo") "bar")

always “works” and problems occur possibly much later, at run time.

> An idea behind this series of patch series seems to be to eliminate
> input labels entirely. Is that true / false?

This is true: it’s a step to make it possible to eventually remove input
labels entirely.

> A benefit of having procedures like 'modify-inputs' instead of having
> random code assume package inputs are alists with a certain structure,
> is that this opens some opportunities to experiment with the nature
> of inputs.

Exactly.

> More specifically, take 'propagated-inputs'.  Guile dependencies of
> guile libraries usually have to be added to 'propagated-inputs',
> even if the library package can also be used as a program.  If the
> user only wants to use it as a program, then the propagation isn't
> necessary.  So introducing some kind of 'context-dependent propagation'
> might be interesting, to reduce propagation conflicts.

Ah ha!  That’s a different can of worms though.  :-)

Thanks,
Ludo’.