Faré wrote:
The cache should ideally be per source-registry entry; and managed by the same entity that manages said entry. Thus, I was thinking of an optional second form in cl-source-registry.conf file. Or a separate .cl-source-registry.cache file.
I saw that. i’m ambivalent about the complexity.
Checking for .cl-source-registry.cache in collect-sub*directories-asd-files should be straightforward. NB: If you're going to hack these things, please use the faster-registry branch.
I'm having a little trouble keeping track of this discussion. Is there a clear argument for this caching to be a core piece of ASDF instead of a contrib? Could the disk cache be handled by code that massages *system-definition-search-functions* in a contrib? Certainly not as currently defined, but with some rejiggering? Or could we add a means to hook the source registry initialization process?
I note also that the quickasdf proposal has no room for people who have multiple *different* lisp configurations. Currently, if you work on different projects, with different library sets, you can change the environment variable to change contexts, you can point your ASDF at different configuration files, or you can use code that changes the value of asdf:*central-registry*. For quickasdf to be an acceptable integration into ASDF proper, it would have to be able to be reconfigurable in exactly the same ways, and guarantee that when users change their current working configuration *in any one of these ways*, they cannot get a some other configuration's disk cache.
So: for the moment, no. Quickasdf's disk cache will NOT be integrated into ASDF. There are way too many open questions.
See my earlier email manifesto as ASDF maintainer, and new follow on.
Best, r