[bug#50960] [PATCH 10/10] shell: Maintain a profile cache.

[Ludovic Courtès]

Maxime Devos <maximedevos@telenet.be> skribis:

> Ludovic Courtès schreef op za 02-10-2021 om 12:22 [+0200]:
>> With this change, running "guix shell" (no arguments) is equivalent to:
>> 
>>   guix environment -r ~/.cache/guix/profiles/some-root -l guix.scm
>> 
>> This is the cache miss.  On cache hit, it's equivalent to:
>> 
>>   guix environment -p ~/.cache/guix/profiles/some-root
>> 
>
> What if guix.scm is something like
>
> ;; Load custom package definitions
> (include "a-package.scm")
> (include "b-package.scm")
> (include "c-package.scm")
> (list a-package b-package c-package bash ...)
>
> and a-package.scm, b-package.scm or c-package.scm is modified?
> Then the cached profile should be rebuild, no?

It should, but it won’t; that’s a weakness of this mtime-based caching
strategy.

I’m not sure how to address it.  We’d need a cache key that’s more
precise than inode/mtime, yet cheap to compute.

Perhaps we need to live with that limitation, document it, and provide a
flag to force a rebuild?

> So I think the cache should also check if these dependencies have been 
> modified.
> To keep track of the dependencies, something like the ‘compile-all,compile:
> Keep track of dependencies of compiled modules.’ patch from
> <https://issues.guix.gnu.org/50384> could be used, though the 'include', 
> 'load',
> 'include-from-path' and maybe 'use-modules' (if something like "guix shell 
> -Lextra-modules-directory ..."
> is done) macros would need to be replaced.

Problem is that any attempt to keep track of dependencies is always an
approximation because macros can do anything—I can have my own macro
that reads files at expansion time.  So I’m inclined to not even try.

Thanks,
Ludo’.