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

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1: Type: text/plain, Size: 3721 bytes --]

Hi,

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.
If "with-inputs" functioned like that, then "search-input-file" wouldn't
be necessary in this case.

Thus, the input label would be by default the package name of the default
package in 'inputs' or 'native-inputs', and if a input is replaced,
then the package name of the original package is still used as label,
but with the new package as value.

(This might or might not currently be the case, I dunno)

So, interpreting
‘The idea is that code should not rely on _package names_ when looking ...’
as ‘The idea is that code should not rely on _labels_ when looking ...’,
I don't agree, as labels (shouldn't) spontanuously change even when using
--with-inputs, so I consider them perfectly fine to use when it's convenient.

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

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

> I initially made the ‘search-input-file’ changes by grepping for
> “(string-append (search-input inputs”, replacing everything in wgrep
> mode.  I then reviewed changes one by one (though without rebuilding
> everything) and committed them in chunks of similar changes for
> easier review/bisecting.
> 
> I’d like to push this to core-updates soonish.
> 
> Feedback welcome!

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

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.

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.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]