GNU bug report logs -
#73073
[PATCH 0/6] Allow origin with label as inputs.
Previous Next
Full log
Message #44 received at 73073 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
This bug report was last modified 237 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.