[bug#73073] [PATCH 0/6] Allow origin with label as inputs.

[Simon Tournier <zimon.toutoune@gmail.com>]

Hi Ludo,

On Fri, 06 Sep 2024 at 23:45, Ludovic Courtès <ludo@gnu.org> wrote:

> This is one reason why I’d rather avoid the change you’re suggesting.
> But more importantly: I think we should avoid polymorphic lists for
> clarity (the principle is followed in most of the code), and
> reintroducing labels would be a step backwards.

This is inaccurate: inputs are already polymorphic lists.  For example,

    (native-inputs (list desktop-file-utils ;for update-desktop-database
                         gettext-minimal
                         `(,glib "bin")
                         itstool
                         pkg-config
                         python))

And “bin” is a label, AFAIU.  That’s said…

> To be clear, I understand the current situation is not perfect, but I
> would rather look for solutions that do not involve undoing what’s taken
> this long to do.

…I agree: my aim is not to revive the “old style”.  Aside, from my
perspective, the main issue with the “old style” is not the labels but
instead it’s the redundancy.

In other words, labels are not the evil since they are still used for
dealing with “outputs”.

Anyway, let avoid the Walder’s law trap [1]. ;-)

So let do not rely on explicit labels.

> The main issue we want to address here is origins being hidden from
> ‘package-direct-sources’, right?

Yes…  And also I think that’s a bad pattern to not have all “inputs“ in
the same place. From my point of view, the current situation defeats my
understanding of declarative programming.


> diff --git a/guix/packages.scm b/guix/packages.scm
> index f373136d22..8b08f0d379 100644
> --- a/guix/packages.scm
> +++ b/guix/packages.scm
> @@ -676,6 +676,8 @@ (define (add-input-label input)
>                "_")
>           ,obj
>           ,@(if (string=? output "out") '() (list output)))))
> +    ((? origin? origin)
> +     (list (or (origin-actual-file-name origin) "_") origin))
>      (x
>       `("_" ,x))))
>  
>
> … meaning we could write (this-package-input "git-manpages.tar.gz") or
> similar.  (This particular change would need tweaks in a few packages
> such as ‘tzdata’ to avoid a full rebuild.)

This solution appears to me the best approach.  Somehow, it uses
’file-name’ as internal “label”.  When internal “labels” will completely
removed, e.g., using package name or else, we will adapt.

Well, ’origin-actual-file-name’ returns for example
"libgd-2.0.4-checkout", i.e. the version would be required when calling
’this-package-input’.  Therefore, it would mean something like:

    #$(this-package-native-input (git-file-name "libgd" version))

This appears to me a good solution.

However, how is it possible to avoid a full rebuild because ’tzdata’ or
else?  It means the package definition cannot be modified, right?
Therefore, the only way would to special case ’maybe-add-input-labels’,
e.g.,

--8<---------------cut here---------------start------------->8---
@@ -441,6 +441,9 @@ (define (maybe-add-input-labels inputs)
   "Add labels to INPUTS unless it already has them."
   (cond ((null? inputs)
          inputs)
+        ((and (pair? (car inputs))
+              (origin? (cdar inputs)) )
+         inputs)
         ((and (pair? (car inputs))
               (string? (caar inputs)))
          inputs)
--8<---------------cut here---------------end--------------->8---

Would it be ok performance-wise?  Or what could the another option?

Moreover, as you said some other packages deep in the graph seem in the
picture.

Well, I am going to explore this in order to send a v2.


Cheers,
simon


1: https://wiki.haskell.org/Wadler%27s_Law