bug#22990: Grafts leads to inefficient substitute info retrieval

[Ludovic Courtès]

address@hidden (Ludovic Courtès) skribis:

> Concretely, what this means is this:
>
>   $ guix package -u
>   substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 
> 100.0%
>   substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 
> 100.0%
>   substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 
> 100.0%
>   substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 
> 100.0%
>   substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 
> 100.0%
>   substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 
> 100.0%
>   substitute: updating list of substitutes from 'http://mirror.guixsd.org'... 
> 100.0%
>   […]
>   The following files would be downloaded:
>
> Each of the initial “updating list” message corresponds to an HTTP
> request for a single narinfo file, which can take around 1 second.
>
> Instead, the ideal thing would be to fetch the narinfo files for all the
> relevant packages at once; that way, we’d spawn ‘guix substitute’ only
> once, and it would benefit from HTTP pipelining (one round-trip instead
> of N.)
>
> To achieve this, I’m thinking of extending gexp code such that gexp
> compilers can return a list of applicable grafts.  The ‘package’
> compiler would do #:graft? #f and instead let ‘gexp->derivation’ call
> ‘graft-derivation’.

The ‘wip-gexp-grafts’ branch does that.  Namely, it’s possible to know
what grafts would apply to a gexp derivation build, so that one can
first build ungrafted, and then apply the grafts to the results.
So for a profile, we’d first build the profile as is, and only then
would we graft it.

Right now the tip of this branch is a hack such that ‘guix package’:

  1. Builds the original (ungrafted) derivation of the profile;

  2. Manually calls ‘graft-derivation’ on that, passing it the list of
     applicable grafts.

Conceptually it’s what we want to do, but the drawback is that the
caller (here ‘guix package’) goes through a lot of hops to get the list
of grafts and to apply it.

I think we should instead have a way to annotate a derivation with a
list of grafts, as well as a procedure to build that derivations in two
phases (first the original derivation, then the grafts).

To be continued…

Ludo’.