Re: Guix pull: avoiding "Computing Guix derivation"

[Richard Sent <richard@freakingpenguin.com>]

>> - 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.