Live data from Hacker News

Cloud Run quietly swaps HOME env var in Docker

chanind.github.io

11–20 of 33 posts

Re: Cloud Run quietly swaps HOME env var in Docker

#12
Cloud Run PM here. Sorry for the inconvenience. This is an issue for which we have a fix, but the fix still needs to roll out (internal bug 154368323 for googlers reading, we're still evaluating the best rollout strategy). Until then, I'll add it to https://cloud.google.com/run/docs/issues.

Re: Cloud Run quietly swaps HOME env var in Docker

#13

As 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.

Agree. It only takes a few lines. But how long does it take to learn what those lines are?

Re: Cloud Run quietly swaps HOME env var in Docker

#14
post #12

Cloud Run PM here. Sorry for the inconvenience. This is an issue for which we have a fix, but the fix still needs to roll out (internal bug 154368323 for googlers reading, we're still evaluating the best rollout strategy). Until then, I'll add it to https://cloud.google.com/run/docs/issues .

Cool beans. Thanks for the response.

Re: Cloud Run quietly swaps HOME env var in Docker

#15

Earlier quoted context omitted.

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.

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.

Re: Cloud Run quietly swaps HOME env var in Docker

#16
post #12

Cloud Run PM here. Sorry for the inconvenience. This is an issue for which we have a fix, but the fix still needs to roll out (internal bug 154368323 for googlers reading, we're still evaluating the best rollout strategy). Until then, I'll add it to https://cloud.google.com/run/docs/issues .

I only say this half in jest: Google, please give this person a raise. I'm not sure I've ever seen a Google PM be this up front and straightforward with a future roadmap item, even in HN, where I more commonly see more direct communications by PMs or engineers from various companies.

While you're at it, if there is a way you can get the Google Identity Platform PM to let us know when some form of multi-factor auth besides SMS will be supported, that would be great!

Re: Cloud Run quietly swaps HOME env var in Docker

#18
post #4

The 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.

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.

[1] https://huggingface.co/transformers/v4.3.3/installation.html...

Re: Cloud Run quietly swaps HOME env var in Docker

#19
post #12

Cloud Run PM here. Sorry for the inconvenience. This is an issue for which we have a fix, but the fix still needs to roll out (internal bug 154368323 for googlers reading, we're still evaluating the best rollout strategy). Until then, I'll add it to https://cloud.google.com/run/docs/issues .

Out of interest what is the trickiness in the roll out? Breaking previously deployed containers that depend on this behavior?

Re: Cloud Run quietly swaps HOME env var in Docker

#20

Does Huggingface not have a way to override the cache directory? I always specify directories like this manually when using docker specifically to avoid issues like the one in TFA.

They do - https://huggingface.co/transformers/v4.3.3/installation.html...
Post reply on HN