Acknowledgement sent
to Simon Tournier <zimon.toutoune@gmail.com>:
New bug report received and forwarded. Copy sent to maxim.cournoyer@gmail.com, guix-patches@gnu.org.
(Fri, 06 Sep 2024 15:52:02 GMT) (full text, mbox, link).
Subject: [PATCH 0/6] Allow origin with label as inputs.
Date: Fri, 6 Sep 2024 17:51:14 +0200
Hi,
As discussed in bug#73034 [1], these 5 packages – farstream,
gnulib-checkout, smithforth, gnome-recipes and dmd-bootstrap – have an
origin inside the ’arguments’ package record.
This is annoying because these origins are hidden from
’package-direct-sources’; see module (guix packages).
I consider this is bug. :-) Hence this prposal for fixing it.
Moreover and tangentially, it appears to me an anti-pattern of the
functional paradigm: The data from the impure outside should be handled
by the ’source’ record field, or otherwise by ’inputs’, ’native-inputs’
or ’propagated-inputs’ record fields; let say only ’inputs’ for
simplicity.
To my knowledge, using the old style with label, we strove on this
principle. However, using the “new style” [2], it does not offer to
have labels with plain package symbol. In other words, for example,
this snippet does not work:
(list gdmd which
`("phobos"
,(origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/dlang/phobos")
(commit (string-append "v" version))))
(file-name (git-file-name "phobos" version))
(sha256
(base32
"1yw7nb5d78cx9m7sfibv7rfc7wj3w0dw9mfk3d269qpfpnwzs4n9"))))))
The reason is because ’sanitize-inputs’; see module (guix packages).
((_ (list args ...))
(add-input-labels args ...))
((_ inputs)
(maybe-add-input-labels inputs))))
Roughly speaking, because the ’inputs’ starts by the term ’list’ then
’add-input-labels’ is applied, else it applies ’maybe-add-input-labels’.
Note that:
(define (add-input-labels . inputs)
"Add labels to all of INPUTS if needed (this is the rest-argument version of
'maybe-add-input-labels')."
(maybe-add-input-labels inputs))
The procedure ’maybe-add-input-labels’ reads: if the first element of
the ’inputs’ record field is using the “old style“ then return all
as-is, assuming all are “old style”. Else apply to all the ’inputs’
elements the procedure ’add-input-label’.
Hence the simple proposal:
--8<---------------cut here---------------start------------->8---
diff --git a/guix/packages.scm b/guix/packages.scm
index f373136d22..5fea44c2bb 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)))))
+ (((? string? label) obj) ;Allow old style as sometimes requires by origin in inputs
+ `(,label ,obj))
(x
`("_" ,x))))
--8<---------------cut here---------------end--------------->8---
This allows to write ’inputs’ as above. :-) As done with the 5 packages.
And it does not hurt the new style. Maybe “guix style” would need to be
adjusted too?
WDYT?
Cheers,
simon
1: [bug#73034] [PATCH v3 0/3] Fix annoyances of Git and update to 2.46.0
Maxim Cournoyer <maxim.cournoyer@gmail.com>
Fri, 06 Sep 2024 13:17:33 +0900
id:87msklct5u.fsf@gmail.com
https://issues.guix.gnu.org/73034https://issues.guix.gnu.org/msgid/87msklct5u.fsf@gmail.comhttps://yhetil.org/guix/87msklct5u.fsf@gmail.com
2: https://guix.gnu.org/en/blog/2021/the-big-change/
Simon Tournier (6):
guix: packages: Allow origin with label as inputs.
gnu: dmd-bootstrap: Move phobos origin from phases to native-inputs.
gnu: smithforth: Move system.fs origin from phases to native-inputs.
gnu: gnome-recipes: Move libgd origin from phases to native-inputs.
gnu: farstream: Move common origin from phases to native-inputs.
gnu: gnulib: Move phobos origin from phases to native-inputs.
gnu/packages/build-tools.scm | 18 ++++++++++--------
gnu/packages/dlang.scm | 22 ++++++++++++----------
gnu/packages/forth.scm | 20 +++++++++++---------
gnu/packages/freedesktop.scm | 24 +++++++++++++-----------
gnu/packages/gnome.scm | 22 ++++++++++++----------
guix/packages.scm | 2 ++
6 files changed, 60 insertions(+), 48 deletions(-)
base-commit: 7d2ced8d6d9c38327592d312376d59a8c37fc160
--
2.45.2
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: Simon Tournier <zimon.toutoune@gmail.com>, 73073@debbugs.gnu.org
Cc: Vivien Kraus <vivien@planete-kraus.eu>,
Maxim Cournoyer <maxim.cournoyer@gmail.com>
Subject: Re: [bug#73073] [PATCH 4/6] gnu: gnome-recipes: Move libgd origin
from phases to native-inputs.
Date: Fri, 06 Sep 2024 19:33:26 +0200
Am Freitag, dem 06.09.2024 um 17:54 +0200 schrieb Simon Tournier:
> * gnu/packages/dlang.scm (gnome-recipes)[arguments]<phases>: Move
> libgd
> origin from here...
> [native-inputs]: ...to here.
>
> Change-Id: I137dc41819a680fdf1f5c0bea9778b2bceae3fad
> ---
> gnu/packages/gnome.scm | 22 ++++++++++++----------
> 1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
> index 7339000436..8ae9fb0656 100644
> --- a/gnu/packages/gnome.scm
> +++ b/gnu/packages/gnome.scm
> @@ -799,15 +799,7 @@ (define-public gnome-recipes
> (add-after 'unpack 'unpack-libgd
> (lambda _
> (copy-recursively
> - #$(origin
> - (method git-fetch)
> - (uri (git-reference
> - (url
> "https://gitlab.gnome.org/GNOME/libgd")
> - (commit
> "c7c7ff4e05d3fe82854219091cf116cce6b19de0")))
> - (file-name (git-file-name "libgd" version))
> - (sha256
> - (base32
> -
> "16yld0ap7qj1n96h4f2sqkjmibg7xx5xwkqxdfzam2nmyfdlrrrs")))
> + #$(this-package-native-input "libgd")
> "subprojects/libgd"))))))
> (inputs (list glib
> gnome-autoar
> @@ -823,7 +815,17 @@ (define-public gnome-recipes
> `(,glib "bin")
> itstool
> pkg-config
> - python))
> + python
> + `("libgd"
> + ,(origin
> + (method git-fetch)
> + (uri (git-reference
> + (url
> "https://gitlab.gnome.org/GNOME/libgd")
> + (commit
> "c7c7ff4e05d3fe82854219091cf116cce6b19de0")))
> + (file-name (git-file-name "libgd"
> version))
> + (sha256
> + (base32
I can see why you're doing that, but I'm not really convinced it helps
the package. Particularly, we're now even adding a labeled input,
which makes for a cursed situation where all but one inputs are
unlabeled¹.
IMHO, G-Expressions in phases serve in part to facilitate uses like
this. They may not be nice, but those are upstream conditions we have
to cope with. I'd rather do a proper unbundling of libgd.
Another "proper" solution could be as easy as using an unlabeled origin
and search-input-file. However, this doesn't really work all that well
if you have to unpack the entire origin, hence what I've done here for
gnome-recipes.
Cheers
¹ Let's not even mention the necessity of 1/6 to enable that. Back in
the day, there was a decision against giving origins labels because it
would add to the further propagation of label use throughout Guix,
while we want to drop them.
Information forwarded
to guix-patches@gnu.org: bug#73073; Package guix-patches.
(Fri, 06 Sep 2024 18:13:02 GMT) (full text, mbox, link).
To: Liliana Marie Prikler <liliana.prikler@gmail.com>, 73073@debbugs.gnu.org
Cc: Vivien Kraus <vivien@planete-kraus.eu>,
Maxim Cournoyer <maxim.cournoyer@gmail.com>
Subject: Re: [bug#73073] [PATCH 4/6] gnu: gnome-recipes: Move libgd origin
from phases to native-inputs.
Date: Fri, 06 Sep 2024 20:11:27 +0200
Hi Liliana,
My aim is not to mix, under ’inputs’ record field, the old style (label)
with the new style (no label) but to have the ’origin’ inside ’inputs’
and not inside ’arguments’.
On Fri, 06 Sep 2024 at 19:33, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:
> I can see why you're doing that, but I'm not really convinced it helps
> the package.
As I wrote in the cover letter:
This is annoying because these origins are hidden from
’package-direct-sources’; see module (guix packages).
So it helps the package. ;-)
Please note that the docstring of ’package-direct-sources’ is currently
lying. ;-) Well, the situation is a bug, IMHO.
--8<---------------cut here---------------start------------->8---
"Return all source origins associated with PACKAGE; including origins in
PACKAGE's inputs and patches."
--8<---------------cut here---------------end--------------->8---
> IMHO, G-Expressions in phases serve in part to facilitate uses like
> this.
I agree that G-exps facilitate manipulation of store paths. But using
’origin’ inside arguments appears to me as an abuse of the feature. As
I wrote in the cover letter:
Moreover and tangentially, it appears to me an anti-pattern of the
functional paradigm: The data from the impure outside should be handled
by the ’source’ record field, or otherwise by ’inputs’, ’native-inputs’
or ’propagated-inputs’ record fields; let say only ’inputs’ for
simplicity.
Therefore, I strongly think ’origin’ should not be inside arguments.
Somehow, my submission is a proposal for dealing with the case. And
it’s not really if it needs to, or should, be done. :-)
> Particularly, we're now even adding a labeled input,
> which makes for a cursed situation where all but one inputs are
> unlabeled¹.
Please note it’s a specific inputs: it’s an ’origin’. This can be
checked by the pattern matching, e.g.,
(((? string? label) (? origin? o) ;Allow old style as sometimes requires by origin in inputs
`(,label ,o))
Other said, it would not be a “cursed situation”; only a situation using
a locally defined input.
Cheers,
simon
Information forwarded
to guix-patches@gnu.org: bug#73073; Package guix-patches.
(Fri, 06 Sep 2024 20:16:01 GMT) (full text, mbox, link).
From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: Simon Tournier <zimon.toutoune@gmail.com>, 73073@debbugs.gnu.org
Cc: Vivien Kraus <vivien@planete-kraus.eu>,
Maxim Cournoyer <maxim.cournoyer@gmail.com>
Subject: Re: [bug#73073] [PATCH 4/6] gnu: gnome-recipes: Move libgd origin
from phases to native-inputs.
Date: Fri, 06 Sep 2024 22:14:02 +0200
Am Freitag, dem 06.09.2024 um 20:11 +0200 schrieb Simon Tournier:
> Hi Liliana,
>
> My aim is not to mix, under ’inputs’ record field, the old style
> (label) with the new style (no label) but to have the ’origin’ inside
> ’inputs’ and not inside ’arguments’.
Sure, but you do introduce a label to make that work is what I'm
saying.
> As I wrote in the cover letter:
>
> This is annoying because these origins are hidden from
> ’package-direct-sources’; see module (guix packages).
>
> So it helps the package. ;-)
>
> Please note that the docstring of ’package-direct-sources’ is
> currently lying. ;-) Well, the situation is a bug, IMHO.
I think we should fix ‘package-direct-sources’ then. The derivation
obviously knows about this input, otherwise the package wouldn't be
built, so the information is there. I'd also hazard a guess that Rust
being Rust, no useful information for Rust packages comes with package-
direct-inputs if arguments aren't being handled.
> --8<---------------cut here---------------start------------->8---
> "Return all source origins associated with PACKAGE; including
> origins in PACKAGE's inputs and patches."
> --8<---------------cut here---------------end--------------->8---
>
>
> > IMHO, G-Expressions in phases serve in part to facilitate uses like
> > this.
>
> I agree that G-exps facilitate manipulation of store paths. But
> using ’origin’ inside arguments appears to me as an abuse of the
> feature. As I wrote in the cover letter:
>
> Moreover and tangentially, it appears to me an anti-pattern
> of the
> functional paradigm: The data from the impure outside should
> be handled
> by the ’source’ record field, or otherwise by ’inputs’,
> ’native-inputs’
> or ’propagated-inputs’ record fields; let say only ’inputs’
> for
> simplicity.
>
> Therefore, I strongly think ’origin’ should not be inside arguments.
We could handle it in source at the cost of similar anti-patterns, or
in inputs at the cost of the anti-pattern you suggest. The Right
Thing™ would be to unbundle these dependencies correctly.
Also note that your argument would apply to #$this-package-input just
as well: it still is magic that pulls in data from the impure outside
world, and you can trivially trick it into doing silly things. (Just
add inheritance.)
> Somehow, my submission is a proposal for dealing with the case. And
> it’s not really if it needs to, or should, be done. :-)
You are working on the implicit assumption that everyone agrees that it
needs to be done, then.
> > Particularly, we're now even adding a labeled input,
> > which makes for a cursed situation where all but one inputs are
> > unlabeled¹.
>
> Please note it’s a specific inputs: it’s an ’origin’. This can be
> checked by the pattern matching, e.g.,
>
> (((? string? label) (? origin? o) ;Allow old style as sometimes
> requires by origin in inputs
> `(,label ,o))
>
> Other said, it would not be a “cursed situation”; only a situation
> using a locally defined input.
It *is* a cursed situation for the person reading the inputs field.
Apart from proper unbundling, some other workarounds would be:
- hacking around search-input-file
- making dummy data packages
- named origins (this one requires similar support code to be written
and has already been rejected once IIRC)
- computed origins
And yes, I label them as workarounds, since they don't address the root
cause of why origins are introduced in arguments.
Sometimes, practicality beats purity: Consider the ungoogled-chromium
recipe if you hadn't had a good scare today. The fact that this
pattern shows up as rarely as it does is a testament to how well Guix
functions otherwise – but there might still be a need for it in some
fringe circumstances. I'd rather we don't change code unless the
result is clearly better™, and I don't see that here.
Cheers
Information forwarded
to guix-patches@gnu.org: bug#73073; Package guix-patches.
(Fri, 06 Sep 2024 21:46:02 GMT) (full text, mbox, link).
Hello,
Simon Tournier <zimon.toutoune@gmail.com> skribis:
> The reason is because ’sanitize-inputs’; see module (guix packages).
>
> ((_ (list args ...))
> (add-input-labels args ...))
> ((_ inputs)
> (maybe-add-input-labels inputs))))
[...]
> The procedure ’maybe-add-input-labels’ reads: if the first element of
> the ’inputs’ record field is using the “old style“ then return all
> as-is, assuming all are “old style”. Else apply to all the ’inputs’
> elements the procedure ’add-input-label’.
Yes: as an optimization, we just check the first element or even just
the syntax (whether the value starts with (list …)).
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.
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.
The main issue we want to address here is origins being hidden from
‘package-direct-sources’, right?
What if we could do this:
… 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.)
WDYT?
Thanks,
Ludo’.
Information forwarded
to guix-patches@gnu.org: bug#73073; Package guix-patches.
(Sat, 07 Sep 2024 13:42:02 GMT) (full text, mbox, link).
To: Liliana Marie Prikler <liliana.prikler@gmail.com>, 73073@debbugs.gnu.org
Cc: Vivien Kraus <vivien@planete-kraus.eu>,
Maxim Cournoyer <maxim.cournoyer@gmail.com>
Subject: Re: [bug#73073] [PATCH 4/6] gnu: gnome-recipes: Move libgd origin
from phases to native-inputs.
Date: Sat, 07 Sep 2024 13:37:46 +0200
Hi Liliana,
I get your points. In order to avoid duplicate discussion, please
consider the Ludo’s thread.
On Fri, 06 Sep 2024 at 22:14, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:
> I'd also hazard a guess that Rust
> being Rust, no useful information for Rust packages comes with package-
> direct-inputs if arguments aren't being handled.
Yes, I am aware of the Rust package case. :-)
It’s similar as the Haskell
package, as I pointed years ago [1]. I still think that’s something
which needs to be improved.
Cheers,
simon
1: Re: Cabal mismatch in ghc-lucid; long-term archiving Haskell?
zimoun <zimon.toutoune@gmail.com>
Mon, 22 Aug 2022 16:04:21 +0200
id:87ilmk5q8q.fsf@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2022-08https://yhetil.org/guix/87ilmk5q8q.fsf@gmail.com
Information forwarded
to guix-patches@gnu.org: bug#73073; Package guix-patches.
(Sat, 07 Sep 2024 13:42:02 GMT) (full text, mbox, link).
Subject: Re: [bug#73073] [PATCH 0/6] Allow origin with label as inputs.
Date: Sat, 07 Sep 2024 15:40:30 +0200
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
Information forwarded
to guix-patches@gnu.org: bug#73073; Package guix-patches.
(Sat, 07 Sep 2024 14:51:02 GMT) (full text, mbox, link).
Subject: Re: [bug#73073] [PATCH 0/6] Allow origin with label as inputs.
Date: Sat, 07 Sep 2024 16:49:36 +0200
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
Information forwarded
to guix-patches@gnu.org: bug#73073; Package guix-patches.
(Tue, 10 Sep 2024 01:29:01 GMT) (full text, mbox, link).
Subject: [PATCH v2 0/8] Allow origin inside inputs with "new style".
Date: Tue, 10 Sep 2024 03:27:08 +0200
Hi,
Following Ludo's advice [1], here the v2.
Packages use ’package-name’ as internal labels so the first patch of the serie
adds ’origin-actual-file-name’ as internal labels for the origins. Then, the
’origin’ is found back via ’this-package-input’ as for the packages.
For instance, without the patch, we have somewhere in the phase:
#$(origin
(method url-fetch)
(uri (string-append
"mirror://kernel.org/software/scm/git/"
"git-manpages-" (package-version this-package) ".tar.xz"))
(sha256
(base32
"1lvvhzypllbyd8j6m0p9qgd3gqg10gch9s7lqif8vr9n80fqn4fw"))))))))))))
then with the patch, this origin is moved to the ’native-inputs’ field and the
snippet above is replaced by:
#$(this-package-native-input
(string-append
"git-manpages-" (package-version this-package) ".tar.xz")))))))))))
Please note the two special cases: tzdata and texlive-hyphen-complete. They
are considered in order to avoid a world rebuild. The final adjusment can be
addressed with some “build train” (or “merge train”) as discussed elsewhere.
The other patches of the series provide more examples of the usage.
WDYT?
Cheers,
simon
1: [bug#73073] [PATCH 0/6] Allow origin with label as inputs.
Ludovic Courtès <ludo@gnu.org>
Fri, 06 Sep 2024 23:45:04 +0200
id:87o750wj6n.fsf@gnu.org
https://issues.guix.gnu.org/73073https://issues.guix.gnu.org/msgid/87o750wj6n.fsf@gnu.orghttps://yhetil.org/guix/87o750wj6n.fsf@gnu.org
Simon Tournier (8):
guix: packages: Allow origin inside inputs with "new style".
gnu: gnome-recipes: Move libgd origin from phases to native-inputs.
gnu: dmd-bootstrap: Move phobos origin from phases to native-inputs.
gnu: smithforth: Move system.fs origin from phases to native-inputs.
gnu: farstream: Move common origin from phases to native-inputs.
gnu: gnulib: Move phobos origin from phases to native-inputs.
gnu: git: Move git-manpages origin from phases to native-inputs.
gnu: cgit: Remove input labels.
gnu/packages/build-tools.scm | 18 ++++----
gnu/packages/dlang.scm | 21 ++++-----
gnu/packages/forth.scm | 20 +++++----
gnu/packages/freedesktop.scm | 24 +++++-----
gnu/packages/gnome.scm | 19 ++++----
gnu/packages/version-control.scm | 75 +++++++++++++++++---------------
guix/packages.scm | 10 +++++
7 files changed, 106 insertions(+), 81 deletions(-)
base-commit: 85a603f58b9b6fef86984a3b2cfc27bd13314ba1
--
2.45.2
To: Liliana Marie Prikler <liliana.prikler@gmail.com>, 73073@debbugs.gnu.org
Cc: Vivien Kraus <vivien@planete-kraus.eu>,
Maxim Cournoyer <maxim.cournoyer@gmail.com>
Subject: Re: [bug#73073] [PATCH v2 2/8] gnu: gnome-recipes: Move libgd
origin from phases to native-inputs.
Date: Tue, 10 Sep 2024 09:58:14 +0200
Hi Liliana,
On Tue, 10 Sep 2024 at 06:30, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:
>> + #$(this-package-native-input (git-file-name "libgd" version))
[...]
>> + (origin
>> + (method git-fetch)
>> + (uri (git-reference
>> + (url "https://gitlab.gnome.org/GNOME/libgd")
>> + (commit "c7c7ff4e05d3fe82854219091cf116cce6b19de0")))
>> + (file-name (git-file-name "libgd" version))
>
> "libgd-checkout" would be both more honest and easier to get right.
Thanks for the feedback.
Cheers,
simon
Information forwarded
to guix-patches@gnu.org: bug#73073; Package guix-patches.
(Mon, 16 Sep 2024 20:15:01 GMT) (full text, mbox, link).
Hi,
Simon Tournier <zimon.toutoune@gmail.com> skribis:
> 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.
Yes, agreed.
> However, how is it possible to avoid a full rebuild because ’tzdata’ or
> else? It means the package definition cannot be modified, right?
When I looked the other day I came up with this:
Subject: Re: [bug#73073] [PATCH v2 1/8] guix: packages: Allow origin inside
inputs with "new style".
Date: Mon, 16 Sep 2024 22:19:37 +0200
Simon Tournier <zimon.toutoune@gmail.com> skribis:
> * guix/packages.scm (add-input-label): Rely on 'origin-actual-file-name' for
> internal inputs labels.
> (maybe-add-input-labels): Special case to avoid world rebuild.
>
> Change-Id: I6ba5352b1b1b8ab810da3730b09cb9db61d6429c
[...]
> @@ -444,6 +444,9 @@ (define (maybe-add-input-labels inputs)
> ((and (pair? (car inputs))
> (string? (caar inputs)))
> inputs)
> + ((and (origin? (car inputs)) ;XXXX: Remove next world rebuild
> + (null? (cdr inputs))) ;special case tzdata
> + (list (list "_" (car inputs))))
I would rather have this hack in ‘tzdata’ itself, along the lines of
what I sent in a previous message.
> @@ -676,6 +679,13 @@ (define (add-input-label input)
> "_")
> ,obj
> ,@(if (string=? output "out") '() (list output)))))
> + ((? origin? origin) ;XXXX: Remove next world rebuild
> + (let ((texlive (package-source
> + (module-ref (resolve-interface '(gnu packages tex))
> + 'texlive-latex))))
> + (if (eq? input texlive)
> + (list "_" origin)
> + (list (or (origin-actual-file-name origin) "_") origin))))
I think this should be avoided, but what is it that causes a rebuild in
this case?
Thanks,
Ludo’.
Information forwarded
to guix-patches@gnu.org: bug#73073; Package guix-patches.
(Thu, 19 Sep 2024 04:39:01 GMT) (full text, mbox, link).
Subject: Re: [bug#73073] [PATCH v2 1/8] guix: packages: Allow origin inside
inputs with "new style".
Date: Mon, 16 Sep 2024 22:42:51 +0200
Hi Ludo,
On Mon, 16 Sep 2024 at 22:19, Ludovic Courtès <ludo@gnu.org> wrote:
> Simon Tournier <zimon.toutoune@gmail.com> skribis:
>
>> * guix/packages.scm (add-input-label): Rely on 'origin-actual-file-name' for
>> internal inputs labels.
>> (maybe-add-input-labels): Special case to avoid world rebuild.
>>
>> Change-Id: I6ba5352b1b1b8ab810da3730b09cb9db61d6429c
>
> [...]
>
>> @@ -444,6 +444,9 @@ (define (maybe-add-input-labels inputs)
>> ((and (pair? (car inputs))
>> (string? (caar inputs)))
>> inputs)
>> + ((and (origin? (car inputs)) ;XXXX: Remove next world rebuild
>> + (null? (cdr inputs))) ;special case tzdata
>> + (list (list "_" (car inputs))))
>
> I would rather have this hack in ‘tzdata’ itself, along the lines of
> what I sent in a previous message.
Yes, indeed tzdata can temporarily transformed into the old style. It
avoids the world rebuild and it’s a modification easier to change than
the one about maybe-add-input-labels. I agree that’s better.
>> @@ -676,6 +679,13 @@ (define (add-input-label input)
>> "_")
>> ,obj
>> ,@(if (string=? output "out") '() (list output)))))
>> + ((? origin? origin) ;XXXX: Remove next world rebuild
>> + (let ((texlive (package-source
>> + (module-ref (resolve-interface '(gnu packages tex))
>> + 'texlive-latex))))
>> + (if (eq? input texlive)
>> + (list "_" origin)
>> + (list (or (origin-actual-file-name origin) "_") origin))))
>
> I think this should be avoided, but what is it that causes a rebuild in
> this case?
It’s about the package texlive-hyphen-complete; it leads to a world
rebuild – as pointed in the cover letter of v2 ;-)
It reads:
(native-inputs
(list ruby-2.7
ruby-hydra-minimal/pinned
;; Build phase requires "docstrip.tex" from TEXLIVE-LATEX.
;; However, adding this package to native inputs would initiate
;; a circular dependency. To work around this, use TEXLIVE-LATEX
;; source, then add "docstrip.tex" to TEXINPUTS before build.
(package-source texlive-latex)
texlive-tex))
then:
(add-before 'build 'include-docstrip.tex
(lambda* (#:key inputs native-inputs #:allow-other-keys)
(let ((docstrip.tex
(search-input-file (or native-inputs inputs)
"tex/latex/base/docstrip.tex")))
Well, we can apply the same hack as tzdata: temporarily revert to the
old style.
Cheers,
simon
Information forwarded
to guix-patches@gnu.org: bug#73073; Package guix-patches.
(Thu, 26 Sep 2024 13:33:02 GMT) (full text, mbox, link).
Subject: Re: [bug#73073] [PATCH v2 1/8] guix: packages: Allow origin inside
inputs with "new style".
Date: Thu, 26 Sep 2024 22:30:57 +0900
Hi Simon,
That's an interesting series!
Simon Tournier <zimon.toutoune@gmail.com> writes:
[...]
>> I would rather have this hack in ‘tzdata’ itself, along the lines of
>> what I sent in a previous message.
>
> Yes, indeed tzdata can temporarily transformed into the old style. It
> avoids the world rebuild and it’s a modification easier to change than
> the one about maybe-add-input-labels. I agree that’s better.
>
>
>>> @@ -676,6 +679,13 @@ (define (add-input-label input)
>>> "_")
>>> ,obj
>>> ,@(if (string=? output "out") '() (list output)))))
>>> + ((? origin? origin) ;XXXX: Remove next world rebuild
>>> + (let ((texlive (package-source
>>> + (module-ref (resolve-interface '(gnu packages tex))
>>> + 'texlive-latex))))
>>> + (if (eq? input texlive)
>>> + (list "_" origin)
>>> + (list (or (origin-actual-file-name origin) "_") origin))))
>>
>> I think this should be avoided, but what is it that causes a rebuild in
>> this case?
>
> It’s about the package texlive-hyphen-complete; it leads to a world
> rebuild – as pointed in the cover letter of v2 ;-)
>
> It reads:
>
> (native-inputs
> (list ruby-2.7
> ruby-hydra-minimal/pinned
> ;; Build phase requires "docstrip.tex" from TEXLIVE-LATEX.
> ;; However, adding this package to native inputs would initiate
> ;; a circular dependency. To work around this, use TEXLIVE-LATEX
> ;; source, then add "docstrip.tex" to TEXINPUTS before build.
> (package-source texlive-latex)
> texlive-tex))
>
> then:
>
> (add-before 'build 'include-docstrip.tex
> (lambda* (#:key inputs native-inputs #:allow-other-keys)
> (let ((docstrip.tex
> (search-input-file (or native-inputs inputs)
> "tex/latex/base/docstrip.tex")))
>
>
> Well, we can apply the same hack as tzdata: temporarily revert to the
> old style.
Would you please send a v3 with the above implemented? Then we could
move forward, I think.
--
Thanks,
Maxim
Added tag(s) moreinfo.
Request was from Ludovic Courtès <ludo@gnu.org>
to control@debbugs.gnu.org.
(Fri, 04 Oct 2024 19:36:02 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.