GNU bug report logs - #49169
[PATCH 00/11] Removing input labels from package definitions

Previous Next

Package: guix-patches;

Reported by: Ludovic Courtès <ludo <at> gnu.org>

Date: Tue, 22 Jun 2021 09:03:01 UTC

Severity: normal

Tags: patch

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: 49169 <at> debbugs.gnu.org
Subject: [bug#49169] [PATCH 00/11] Removing input labels from package definitions
Date: Sun, 27 Jun 2021 13:00:27 +0200
Hi!

Ludovic Courtès <ludo <at> 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’.




This bug report was last modified 3 years and 352 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.