GNU bug report logs - #70895
[PATCH] grafts: Only compute necessary graft derivations.

Previous Next

Package: guix-patches;

Reported by: David Elsing <david.elsing <at> posteo.net>

Date: Sun, 12 May 2024 13:44:02 UTC

Severity: normal

Tags: patch

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: David Elsing <david.elsing <at> posteo.net>
Cc: 70895 <at> debbugs.gnu.org
Subject: [bug#70895] [PATCH] grafts: Only compute necessary graft derivations.
Date: Sun, 19 Jan 2025 00:01:07 +0100
Hi David,

Sorry for not replying earlier.

David Elsing <david.elsing <at> posteo.net> skribis:

>> While this does the job, it breaks an abstraction (grafts are
>> lower-level than packages) and creates a circular dependency between
>> (guix grafts) and (guix packages) as a result (not technically a problem
>> at this point, but it shows that something’s deserves to be clarified).
>>
>> Maybe there’s a simpler way to achieve this though.  What about allowing
>> monadic values in the ‘origin’ and ‘replacement’ fields of <graft>?
>> Their values would be bound lazily, only when needed by
>> ‘graft-derivation’.
>
> Yes, that's a good idea, this makes the patch a lot shorter as well.
> The 'origin' field need to computed anyway to check whether the graft is
> applicable, so only the 'replacement' field needs to be bound lazily.
>
> In cumulative-grafts, I check whether the replacement field is a monadic
> value using 'procedure?' and then call 'run-with-store'. Is there a
> better way to do this? I see that values in the %state-monad are
> repesented as plain lambdas. Also, is it correct to set the
> #:guile-for-build and #:system keyword arguments here, as they are
> already specified in package->derivation and package->cross-derivation?

What you did is correct.  #:guile-for-build and #:system are use to
specify the default value in case it’s not already specified; passing
them here is unnecessary but it cannot hurt.

> As an alternative, is it possible to 'ungexp' a value in the store monad
> which returns a derivation? Then the derivation for the 'replacement'
> field could be calculated in 'mapping' in 'graft-derivation/shallow'.
> I wouldn't know how to define a gexp-compiler though, except by defining
> one for any procedure and assuming it is a value in the store monad.

I’m not sure what you mean since there’s no gexp here.

Ludo’.




This bug report was last modified 106 days ago.

Previous Next


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