Cloud Run quietly swaps HOME env var in Docker
chanind.github.io
Cloud Run quietly swaps HOME env var in Docker
1–10 of 33 posts
Re: Cloud Run quietly swaps HOME env var in Docker
#2The solution here is to use `$XDG_CACHE_HOME` instead of `$HOME/.cache`, which may not be where a user wants their cache to live: https://specifications.freedesktop.org/basedir-spec/basedir-...
Re: Cloud Run quietly swaps HOME env var in Docker
#3The solution here is to use `$XDG_CACHE_HOME` instead of `$HOME/.cache`, which may not be where a user wants their cache to live: https://specifications.freedesktop.org/basedir-spec/basedir-...
Is that variable set to a consistent value at both build & run in Cloud Run?
Re: Cloud Run quietly swaps HOME env var in Docker
#4The solution here is to use `$XDG_CACHE_HOME` instead of `$HOME/.cache`, which may not be where a user wants their cache to live: https://specifications.freedesktop.org/basedir-spec/basedir-...
$XDG_CACHE_HOME is usually not set, it is an override and software should default to $HOME/.cache.
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.
Re: Cloud Run quietly swaps HOME env var in Docker
#5As an alternative, don’t use root for Dockerfiles. Ever. It only takes a few lines to create a user, group, and use said user, and closes a whole class of security issues.
Re: Cloud Run quietly swaps HOME env var in Docker
#6As an alternative, don’t use root for Dockerfiles. Ever. It only takes a few lines to create a user, group, and use said user, and closes a whole class of security issues.
Closes security loopholes, increases operational burden (if only slightly). A tale as old as time.
Re: Cloud Run quietly swaps HOME env var in Docker
#7As an alternative, don’t use root for Dockerfiles. Ever. It only takes a few lines to create a user, group, and use said user, and closes a whole class of security issues.
True! That would have also been a smart move
Re: Cloud Run quietly swaps HOME env var in Docker
#8For those not familiar with Cloud Run, it's a Google Cloud service that allows you to run Docker containers without managing the server it runs on.
Re: Cloud Run quietly swaps HOME env var in Docker
#9The solution here is to use `$XDG_CACHE_HOME` instead of `$HOME/.cache`, which may not be where a user wants their cache to live: https://specifications.freedesktop.org/basedir-spec/basedir-...
$XDG_CACHE_HOME is usually not set, it is an override and software should default to $HOME/.cache. 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.
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?
Re: Cloud Run quietly swaps HOME env var in Docker
#10Earlier quoted context omitted.
$XDG_CACHE_HOME is usually not set, it is an override and software should default to $HOME/.cache. 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.
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 somethin…
> 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.