all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ulf Herrman <striness@tilde.club>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Ulf Herrman <striness@tilde.club>, 65665@debbugs.gnu.org
Subject: bug#65665: package-mapping with #:deep? #t doesn't get all the implicit inputs
Date: Sat, 21 Oct 2023 17:22:10 -0500	[thread overview]
Message-ID: <8734y3r4z1.fsf@tilde.club> (raw)
In-Reply-To: <87wmvgoxn7.fsf@gnu.org> ("Ludovic Courtès"'s message of "Sat, 21 Oct 2023 16:31:08 +0200")

[-- Attachment #1: Type: text/plain, Size: 3686 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> I don’t know, should we start by having a proper bug report for this and
> study how this happen?

Does that mean opening a new issue, or what?  The bug you've described
is the one this issue was initially opened for.

> Again I’m sorry if I’m slow to understand, but I’d like to make sure we
> have a good understanding of the problem before we start discussing
> solutions.

Okay, I suppose I should have given a concrete example of the behavior.
The qgit example can fill that role:

$ cat $(./pre-inst-env guix build qgit -n --derivations --no-grafts --with-latest=qtbase)
<observe that an untransformed qtbase is present>

The way this happens is that qt-build-system's bag-builder
(e.g. qt-build, qt-cross-build)) introduces a reference to the qtbase
from its #:qtbase argument into the gexp it creates a derivation from,
completely independently of any inputs.  qgit doesn't explicitly specify
#:qtbase, and qt-build-system's 'lower' procedure doesn't add one, so
the default value for that keyword argument, (default-qtbase), is used
in qt-build.

This default value can only be overridden by explicitly passing #:qtbase
as a package or bag argument.  This requirement doesn't map well to a
generic package transformation interface at all - it requires that every
transformer (e.g. package-mapping) check if the package it's
transforming is using qt-build-system, and if so explicitly supply a
#:qtbase that is the result of transforming the original implicit or
explicit value, after somehow figuring out what that may be (currently
only doable by manually reading guix/build-system/qt.scm).

This behavior is also currently exhibited by all build systems' handling
of #:guile.  Here's a concrete example of that, taken from another
mailing I sent to this issue (https://issues.guix.gnu.org/65665#15):

---------------------------------
(use-modules (guix packages)
             (guix profiles)
             (gnu packages base))

(define guile-named-lyle
  (package
    (inherit (default-guile))
    (name "lyle")))

;; contrived example that only replaces hello's immediate dependencies
(define hello-transformer
  (package-mapping (lambda (p0)
                     (if (eq? p0 (default-guile))
                         guile-named-lyle
                         p0))
                   (lambda (p)
                     (not (eq? p hello)))
                   #:deep? #t))

(define hello-with-lyle
  (hello-transformer hello))

(packages->manifest (list hello hello-with-lyle))

;; $ guix build --derivations --manifest=THISFILE
;; Expectation: build for hello-with-lyle is done with guile-named-lyle.
;; Reality: derivation for hello-with-lyle is the same as hello.
---------------------------------

Hopefully that makes it clear why this is happening.

As for solutions, some options that come to mind:

1. guile and qtbase, instead of being passed to bag builders as a
   separate argument, are passed as a bag input that is looked up by
   magic input label, e.g. "guile-for-build", "qtbase-for-build", etc.
   Seems fragile, but requires no changes to package-mapping, etc.

2. Modify the build systems so that these kinds of implicit arguments
   that are packages are always present in bags, and the defaults for
   those keyword arguments in e.g. qt-build are never used.  This is the
   approach I've taken with
   https://issues.guix.gnu.org/issue/65665/attachment/4/0/3.  This still
   requires that bag arguments that are packages are transformed in
   addition to inputs.

I hope that counts as a proper bug report.

- Ulf

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

  reply	other threads:[~2023-10-21 22:22 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-31 20:14 bug#65665: package-mapping with #:deep? #t doesn't get all the implicit inputs Ulf Herrman
2023-09-01 18:08 ` Csepp
2023-09-03 13:02 ` Maxim Cournoyer
2023-09-05 14:57 ` Simon Tournier
2023-09-16  9:45 ` bug#65665: [PATCH] Really " Ulf Herrman
2023-10-06  2:36   ` Maxim Cournoyer
2023-10-06  7:37     ` Ulf Herrman
2023-10-07  3:47       ` Ulf Herrman
2023-10-12 13:47       ` bug#65665: package-mapping with #:deep? #t doesn't " Ludovic Courtès
2023-10-12  7:07     ` bug#65665: [PATCH] Really " Ludovic Courtès
2023-10-12 14:22     ` Simon Tournier
2023-10-12 14:06   ` bug#65665: package-mapping with #:deep? #t doesn't " Ludovic Courtès
2023-10-12 16:00     ` Maxim Cournoyer
2023-10-14 14:47       ` Ludovic Courtès
2023-10-13  3:11     ` Ulf Herrman
2023-10-14 15:18       ` Ludovic Courtès
2023-10-15  7:12         ` Ulf Herrman
2023-10-21 14:31           ` Ludovic Courtès
2023-10-21 22:22             ` Ulf Herrman [this message]
2023-10-23 13:53               ` Simon Tournier
2023-10-12 13:53 ` Ludovic Courtès
2023-10-12 15:53   ` Maxim Cournoyer
2023-10-13  1:49     ` Ulf Herrman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8734y3r4z1.fsf@tilde.club \
    --to=striness@tilde.club \
    --cc=65665@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.