Re: Improving the speed of guix time-machine for development environments

[Richard Sent]

Hi Ludo!

Ludovic Courtès <ludo@gnu.org> writes:

> I understand and share the frustration regarding performance.
>
> To address the problem, I would suggest a different route (the problem
> with the patch you propose here is that it makes things unpredicatable
> and stateful: you’d end up using whatever commit happens to be already
> in a profile).
>
> My suggestion would be for ‘guix pull’ to populate the same cache that
> ‘guix time-machine’ uses.  That way, if you time-travel to a commit you
> already have in a profile, it would be instantaneous.
>
> I started looking into it a while back and there were some
> complications, but I forgot the details.
>
> WDYT?  Would this be an improvement for you?

Thanks for the suggestion! If I understand correctly, I don't believe it
would solve my problems with time-machine though for development
environments.

If I want to use time-machine as part of entering a development
environment for some channel collection and a new guix commit is pushed,
then the next time I invoke that same time-machine command there will be
a large delay as Guix fetches, authenticates, computes, and builds an
entirely new derivation. With your proposal, I'd only avoid that problem
if I coincidentally happened to run guix pull in-between.

I don't believe hard-pinning the guix channel is an appropriate solution
in this case since it has several drawbacks as discussed in [1].

I don't envision this as something to be used in all cases (like
reproducible research). I think it serves as a "yes, this project
requires channel X, but the odds of breakage due to an update are very
low and we are willing to make that tradeoff in order to enter our
development tools faster".

Obviously if breakage is detected in the development environment
developers can choose to go back and hard-pin as required. But if we
hard-pinned from the beginning we wouldn't detect that breakage as
quickly. And if we didn't pin at all we'd have no speedup.

Is it really any different state-wise than pinning a channel to a moving
target like a branch? Instead of being unpredictable and stateful in the
time domain, it's unpredictable and stateful in the user's "profile
domain", for lack of a better phrase.

Perhaps as a compromise we can support optionally passing some "minimum
commit" (or tag). This should reduce the fragility of soft-pinning as it
ensures some minimum version of the channel is present.

If that's not enough, a warning could be emitted so user's know that
soft-pinning is taking place and what commit is used. I'd prefer to
avoid this, but it is an option.

>> I think this is a side effect of time-machine serving dual purposes.
>> One is providing a reproducible environment for result replication,
>> the other is providing a development environment for collections of
>> channels.

[1]: https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00265.html

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.