[bug#49169] [PATCH 00/11] Removing input labels from package definitions

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

Hi!

Ludovic Courtès <ludo@gnu.org> skribis:

> This patch series does the ground work to remove input labels
> from package definitions.  In other words:
>
>   (package
>     ;; …
>     (inputs `(("libunistring" ,libunistring)
>               ("libffi" ,libffi))))
>
> becomes:
>
>   (package
>     ;; …
>     (inputs (list libunistring libffi)))
>
> Note that it does not change the value returned by ‘package-inputs’
> & co.: that still includes input labels.  Likewise, build-side code
> does not see any difference (there are still input alists).

The 2nd phase of this change (could be a year from now) would be to
remove labels entirely from the API: ‘package-inputs’ and related
procedures would return a label-less list.  We’d most likely keep the
‘%build-inputs’ and ‘inputs’ alists on the build side.

However, this phase will be trickier.  Labels currently serve as an
indirection to implement “virtual dependencies”, as in this example:

  (package
    ;; …
    (arguments '(… (assoc-ref inputs "mpi") …))
    (inputs `(("mpi" ,openmpi))))

Here you can replace ‘openmpi’ with ‘mpich’ or ‘my-custom-openmpi’
(through inheritance or with ‘--with-input’) and the build-side code in
‘arguments’ still behaves as expected.

Once labels have fully disappeared, the build-side ‘inputs’ could only
contain the real package name, so either “openmpi” or “mpich”.

We could replace the build-side ‘assoc-ref’ with host-side code like:

  (package
    ;; …
    (arguments
      (list #:phases
            #~(… #$(lookup-package-input this-package "openmpi") …))))

but again, it depends on the actual package name, so it doesn’t help.

So we need… something else.

I don’t think it’s a showstopper for this patch series, but it does mean
that for the time being one has to know about labels to understand what
happens in package variants.

Ludo’.