Use a different cache dir when LIMA_HOME is set to a different path

[lima-vm]

Use a different cache dir when LIMA_HOME is set to a different path

[AkihiroSuda]

Maybe:

• ~/Library/Caches/lima: when $LIMA_HOME is unset or set to the default value
• ~/Library/Caches/lima-<hash of LIMA_HOME>: when $LIMA_HOME is set to a non-default value

[jandubois]

• ~/Library/Caches/lima-<hash of LIMA_HOME>: when $LIMA_HOME is set to a non-default value

I prefer the directory names to be human-readable and not just some hash magic. Right now I can do this:

$ cd ~/Library
$ fd rancher-desktop
Caches/rancher-desktop
State/rancher-desktop
Preferences/io.rancher.rancher-desktop.plist
Preferences/rancher-desktop
Saved Application State/io.rancher.rancher-desktop.savedState
Application Support/KeyCue/Key Counts/rancher-desktop.plist
Application Support/KeyCue/Application Icons/rancher-desktop.tif
Application Support/rancher-desktop
Application Support/CrashReporter/rancher-desktop_BB91A231-8B81-5794-8293-FC46153BEB40.plist

So if there was a rancher-desktop specific lima cache directory, then I would prefer that it would be similarly discoverable. If I could, I would set LIMA_CACHE=$HOME/Library/Caches/rancher-desktop/lima.

If you are really opposed to another env var, then maybe putting the cache under $LIMA_HOME/_cache would feel better to me. I'm still undecided on whether not using ~/Library/Caches would bother me. But then we are not using ~/Library/Logs either, so I don't know.

Normally I would rather have LIMA_HOME/cache and $LIMA_HOME/instances, but that would eat up even more previous characters from the max socket name length. FWIW, this is also very similar to the layout that minikube is using. 😄

Somehow I come back to the position that this is all unnecessary complexity, and just providing a second env variable to let an embedding application decide if it wants to share the lima cache or not would be both the simplest and the most flexible thing.

Note that for Rancher Desktop this discussion is mostly hypothetical because it likely won't be using the lima cache. It already contains logic for caching different k3s versions. That code is needed on Windows, where we are using WSL2. And having control over the caching logic also allows for better error reporting when something goes wrong.

[AkihiroSuda]

Does macOS provide any tool for cleaning up ~/Library/Caches as in Windows Disk Cleanup?
(AFAIK not)

If not, I guess there is no advantage in using ~/Library/Caches, and we can just use $LIMA_HOME/_cache

[jandubois]

Does macOS provide any tool for cleaning up ~/Library/Caches as in Windows Disk Cleanup?

I'm not aware of any tool either. I just tested "Safe Boot", which does clean up system caches, but it did not touch ~/Library/Caches (or /Library/Caches).

On other idea I had: if lima starts using a config file, e.g. $LIMA_HOME/config.yaml, then this could be another mechanism to customize this without requiring an extra env variable. And it would just default to ~/Library/Caches/lima if the config file doesn't exist, or the cache setting hasn't been provided. But maybe again making it needlessly complicated?

[jandubois]

I just had another thought about the cache directory: lima could continue to use a shared ~/Library/Caches/lima directory unless the user (or embedding application) explicitly creates a $LIMA_HOME/_cache directory themselves.

This provides additional flexibility and leaves the default location as-is.

The documentation should mention that it is the responsibility of the user (or embedding application) to exclude the $LIMA_HOME/_cache directory from Time Machine. The default location is automatically excluded:

$ tmutil isexcluded ~/Library
[Included]    /System/Volumes/Data/Users/jan/Library
$ tmutil isexcluded ~/Library/Caches/
[Excluded]    /System/Volumes/Data/Users/jan/Library/Caches
$ tmutil isexcluded ~/Library/Logs
[Excluded]    /System/Volumes/Data/Users/jan/Library/Logs

This raises the question if ~/.lima should be excluded by default, as backing up 100GB files every time there is a change is rather impractical. But I just checked VMWare Fusion and VirtualBox, and neither one excludes their VM directories automatically and leave it to the user. So maybe this too should just be documented instead?

[AkihiroSuda]

SGTM