Is there any built-in functionality allowing to clean-up unused packages from the local cache?
I've been thinking about a small command-line application that parses the conaninfo.txt files in a given root directory (recursively) and matches the packages listed in them against all local packages and removes the difference.
Hi @Blubbz0r,
I see a command like this one could be useful but the problem I see is that the definition of unused can be different from one user to another so it will be difficult to reach a consensus and we will end up with a command full of flags and options.
Anyway, we can leave this request open and see if there is some feedback from the community regarding this. Thanks!
The only thing that might be viable would be:
This sounds particularly important for automated systems like CI infrastructure. Without some form of automatic cleanup they will accumulate a lot versions for all the dependencies and eventually the system will run out of disk space.
So yeah, storing the last recently used date like @memsharded suggested along with a configurable storage quota for conan would be a nice solution. That way it can clean the least used library version from disk when it exceeds the quota.
Hi @tfar
At the moment the best policy is to periodically remove the Conan cache. Specially in CI systems, the Conan cache should be one Conan cache per job, because the cache is NOT concurrent. Having multiple jobs accessing at the same time the Conan cache might produce race conditions. Then probably you want to remove the cache together with other data of the CI build job, when the CI job is old.
You might find interesting the latest "download cache": https://docs.conan.io/en/latest/configuration/download_cache.html, which can be shared between different CI jobs. Still it doesn't implement yet any LRU strategy, but in the worst case you can still delete it periodically, at the end of the day it is just an optimization.
The LRU strategy will be likely implemented at some point, it just didn't get enough priority yet, functional requirements are of much higher priority, especially now we are starting to think about Conan 2.0
Most helpful comment
The only thing that might be viable would be: