Re: Guix pull: avoiding "Computing Guix derivation"

[Richard Sent]

>> - Why is this step not substitutable ? The inputs are known, a hash can
>> be derived, a substitute server could be queried for an output of that
>> hash ? What am I missing ? Does the guix derivation not end up in the
>> store ? What makes it so special that it can't be served by a substitute
>> server ?
>
>It’s not substitutable because it’s not a derivation.  It’s not a
>derivation because it needs to access the store to “compute the Guix
>derivation”.

I see that build in build-self.scm isn't a derivation, but most of the time 
spent in build is, to my knowledge, while the daemon is building the 
build-program derivation. build-program in build-self.scm returns a 
gexp->script file-like object and I see various 
/gnu/store/*-compute-guix-derivation.drv files in my store.

Ergo, if more of the inputs to build-program were locked, the 
compute-guix-derivation output should be substitutable. To my knowledge the 
problem largely lies in that the modules imported in build-self.scm are from 
the current Guix, which vary wildly between machines and is rarely, if ever, 
substitutable. In theory if those modules were pinned to particular versions, 
the bulk of the time spent in build would be removed.

Obviously there are challenges with this approach. For one, if we were to use 
the "guix" package to run build and generate compute-guix-derivation.drv, what 
would we do if a user on Guix A wanted to upgrade/downgrade to B, but the Guix 
package was changed in-between?

I think the various problems are solvable, perhaps by making the solution 
opt-in. e.g. $ guix pull --quick, which attempts to build channels using an 
infrequently updated Guix/Guix-subset to more regularly match an existing 
compute-guix-derivation in a substitute server's store.

Sorry if the formatting on this is off, sent from my phone.