It does appear to[1], and it does help because you can set XDG_CACHE_HOME in your dockerfile so it'll be the same across all runs. I think that's what the GP was getting at.
This has always seemed sort of passive-aggressive on the part of the spec. "No, memorizing our various custom env var names is not sufficient. Developers must also implement our custom logic, and immediately update whenever the logic changes!" That seems a bit much to ask. Why not just trust the user, who will set the env vars if she really wants to use this scheme and who will do something else if she wants something else?
> will do something else if she wants something else
How should that be communicated by the user? A prompt when opening every application asking where you'd like the data, config, state, and cache dirs to live? And if so, how would the application figure out where that config is stored?
These env vars are explicitly only (with the exception of XDG_RUNTIME_DIR) for when the user cares to override them.
Somehow lots of software functioned before the advent of XDG. Lots of software that knows nothing about XDG still functions.
These env vars are explicitly only (with the exception of XDG_RUNTIME_DIR) for when the user cares to override them.
Yeah, sure, that's what the spec says, and that's what is passive-aggressive. There is a complicated system and it is opt-out, which is considered abusive whenever anyone else does it.
I actually like XDG, and I use it even when I have to specifically tell packages to do so. I have contributed patches to unrelated software for XDG support. However, I don't agree with the common online strategy of shitting on software that doesn't follow a spec that is deliberately more complicated than it needs to be.
As per your link:
> If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.
So even if Huggingface is aware of that variable (and it probably is) that won't help at all.