bug#44254: Performance of package input rewriting

[Ludovic Courtès]

Hi,

Lars-Dominik Braun <ldb@leibniz-psychology.org> skribis:

>> I guess it’s easy to end up creating huge object graphs.  Here’s an
>> example of an anti-pattern:
>> 
>>   (define a
>>     ((package-input-rewriting x) ((package-input-rewriting y) p1))) 
>> 
>>   (define b
>>     ((package-input-rewriting x) ((package-input-rewriting y) p2)))
>> 
>> The correct use is:
>> 
>>   (define transform
>>     (package-input-rewriting (append x y)))
>> 
>>   (define a (transform p1))
>>   (define b (transform p2))
> that sounds like a section for the cookbook :)

Note that there’s a new section in the manual on this topic:

  https://guix.gnu.org/manual/devel/en/html_node/Defining-Package-Variants.html

>> It seems to me that you’re redefining a dependency graph, node by node.
>> Thus, you probably don’t need ‘package-input-rewriting’ here.  What you
>> did in Guix-Science commit 972795a23cc9eb5a0bb1a2ffb5681d151fc4d4b0
>> looks more appropriate to me, in terms of style and semantics.
> Okay, got it. My initial concern was that rewriting the graph “by hand” (i.e.
> alist-delete) would be tedious and error-prone.

I haven’t looked closely enough.  If you can define a single procedure
that rewrites the graph, that’s of course better than rewriting nodes
one by one.  Maybe that’s possible, but you need to be careful about
factorizing the transformation procedure as I shown above.

Thanks,
Ludo’.