GNU bug report logs - #66510
`this-package' references reintroduce pre-transformation packages.

Previous Next

Package: guix;

Reported by: Ulf Herrman <striness <at> tilde.club>

Date: Fri, 13 Oct 2023 03:59:02 UTC

Severity: normal

Merged with 50335

To reply to this bug, email your comments to 66510 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#66510; Package guix. (Fri, 13 Oct 2023 03:59:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ulf Herrman <striness <at> tilde.club>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Fri, 13 Oct 2023 03:59:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ulf Herrman <striness <at> tilde.club>
To: bug-guix <at> gnu.org
Subject: `this-package' references reintroduce pre-transformation packages.
Date: Thu, 12 Oct 2023 22:57:14 -0500
[Message part 1 (text/plain, inline)]
Suppose you have a package that is using a gexp in its argument list
and, like a good citizen of the gexp world, it uses this-package-input
to refer to its own input packages.  In fact, let's suppose that it's
the model citizen depicted in
https://guix.gnu.org/en/blog/2021/the-big-change/ under the
"G-expressions and self-referential records" heading:

(define hello
  (package
    (name "hello")
    ;; …
    (arguments
     (list #:configure-flags
           #~(list (string-append "--with-gawk="
                                  #$(this-package-input "gawk")))))
    (inputs `(("gawk" ,gawk)))))

If we define a variant like so:

(define hello-variant
  (package
    (inherit hello)
    (name "hello-variant")
    (inputs `(("gawk" ,gawk-4.0)))))

it will work just fine.  But if we define a variant like SO:

(define hello-variant
  (package
    (inherit hello)
    (name "hello-variant")
    (inputs `(("gawk" ,gawk-4.0)))
    (arguments
     (substitute-keyword-arguments (package-arguments hello)
       ((#:configure-flags flags #~'())
        #~(cons "--with-hospitality=ice-cream"
                #$flags))))))

it will NOT work just fine.  When (package-arguments hello) is
evaluated, it will execute the field definition for `hello' with
`this-package' bound to `hello', rather than `hello-variant'.
Consequently, `this-package-input' will return gawk rather than
gawk-4.0.  We need a way to access the "parent" package's fields while
keeping `this-package' bound to its current value.  The most general
form of this would look something like this:

(define (package-arguments-with-package p0 p)
  (match p0
    (($ <package> _ _ _ _ arguments-proc)
     (arguments-proc p))))

Then hello-variant could be changed to use
(package-arguments-with-package hello this-package)
instead of (package-arguments hello).  This may be needlessly general,
though; the problem could also be solved with an interface more along
the lines of

(parent-package-arguments hello)

which expands into the aforementioned package-arguments-with-package
call.

Another option would be to, yet again, extend the record syntax.  It's
always bugged me a bit to have to explicitly reference the original
record in more than one place when using derived fields, so this might
be generally useful as well:

(define hello-variant
  (package
    (inherit hello
     (arguments hello-arguments))
    (name "hello-variant")
    (inputs `(("gawk" ,gawk-4.0)))
    (arguments
     (substitute-keyword-arguments hello-arguments
       ((#:configure-flags flags #~'())
        #~(cons "--with-hospitality=ice-cream"
                #$flags))))))

This would create a macro named `hello-arguments' within the scope of
the (package ...) form which expands into something equivalent to a
`parent-package-arguments' call.  Adjust syntax to taste.

Thoughts?

- Ulf
[signature.asc (application/pgp-signature, inline)]

Forcibly Merged 50335 66510. Request was from Ulf Herrman <striness <at> tilde.club> to control <at> debbugs.gnu.org. (Sat, 21 Oct 2023 22:35:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#66510; Package guix. (Tue, 09 Apr 2024 14:08:02 GMT) Full text and rfc822 format available.

Message #10 received at 66510 <at> debbugs.gnu.org (full text, mbox):

From: Jake <jforst.mailman <at> gmail.com>
To: 66510 <at> debbugs.gnu.org
Subject: Unexpected `this-package(-native)-input`
Date: Tue, 9 Apr 2024 14:06:55 +0000
[Message part 1 (text/plain, inline)]
Hi Ulf

Has any progress been made on this?

I ran into the same thing, except with native-inputs instead of inputs.
I spent a fair amount of time trying to pin it down, since I don't know
much guile and it requires a combination of conditions to manifest.
Is it worth documenting this behaviour? Or do we expect a solution will be
implemented soon enough?

For now, is the following guideline accurate enough to avoid these
surprises?

If we inherit a package that uses (either directly or through inheritance)
this-package-native-input (or this-package-input), we should not modify the
native inputs (or inputs) via replace if substitute-keyword-arguments is
used anywhere in the inheritance chain.

Thanks
Jake
[Message part 2 (text/html, inline)]

This bug report was last modified 1 year and 163 days ago.

Previous Next


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