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

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi Simon,

since you pointed me here, I will chime in a little :)

Am Samstag, dem 07.09.2024 um 15:40 +0200 schrieb Simon Tournier:
> 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…
Not in the sense that you are addressing inputs with it, no.  "bin" is
an output selector (output "label" if you will) – its purpose it to
choose an output that isn't "out".

> > 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.
But you are adding explicit labels here.  A solution that doesn't would
be much preferred.

> > 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.
I agree with you that inputs outside of inputs should be avoided, but I
disagree with your point on declarative programming.  Packages, even
written in that style, are still declarative.

> > 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.
It doesn't to me.  What do you do if the libgd version changes?  To
arrive at a proper label, you would have to strip the versioning and
packaging metadata – otherwise you're left with a situation, where you
can't replace the package by tweaking inputs anyway.

> 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?
I don't think this does what you think it does.
It returns inputs as-is if the tail of the first input is an origin…
which I don't think would be the case even if we do implement your v1.


Cheers