os: add func UserCacheDir() string

[bradfitz]

I've seen a dozen or so implementations of looking up the user's cache directory.

The latest is from @rsc in:

https://go-review.googlesource.com/c/go/+/68116/3/src/cmd/go/internal/cache/default.go

Which says:

// TODO(rsc): This code belongs somewhere else,
// like maybe ioutil.CacheDir or os.CacheDir.

Some examples of other implementations:
https://godoc.org/go4.org/xdgdir
https://godoc.org/camlistore.org/pkg/osutil#CacheDir
https://github.com/golang/crypto/blob/bd6f299fb381e4c3393d1c4b1f0b94f5e77650c8/acme/autocert/listener.go#L142

Consolidate into std?

[rsc]

Yes, I think we should do this. The windows docs I found said to use %localappdata% for caches, which none of those do. And I know of other copies in the dashboard scraper that (incorrectly) use $HOME/.cache on macOS, and so on. This definitely seems worth putting into the standard library.

Reading the actual definitions of ioutil.TempDir and os.TempDir, this looks closer to os.TempDir (return $TMPDIR) than ioutil.TempDir (make and return a fresh dir under $TMPDIR), so it should probably be os.CacheDir.

Probably should leave for Go 1.11 at this point.

[mvdan]

What about a config/data variant? It's similarly tricky to get right.

[bradfitz]

The os/user package might be a good place for this, since it os/user would likely be a dependency anyway, to find the current user and their $HOME.

[rsc]

If we put it in os/user then it's harder for cmd/go to use it (it cannot depend on cgo for bootstrap). I don't believe os/user is necessary for XDG anyway - the spec very clearly says $HOME not "the user's home directory".

[mvdan]

Perhaps a silly question, but wouldn't this be a bit limited then? If a Go program is run outside a shell, $HOME would likely not be set.

[rsc]

@mvdan that's not very specific. What execution environment do you have in mind that does not set $HOME?

[mvdan]

I was thinking anything that doesn't get run under a shell. I was hoping to demonstrate this with an empty docker container just running a Go program printing $HOME, but it seems like docker has a fallback of HOME=/ in that case.

Systemd also came to mind, but it seems to also take care of the variable on its own. And, on Linux, login programs apparently set it too, so opening a terminal without a shell still has $HOME present.

I thought that relying on this variable was more fragile than it actually is - my bad. Still curious if any reasonable execution environment wouldn't have it set.

[rsc]

It sounds like we should do this, as os.UserCacheDir. Per discussion with @bradfitz, let's run with $HOME (not using os/user) until we know a compelling reason to need the fallback.

[gopherbot]

Change https://golang.org/cl/78835 mentions this issue: os: add func UserCacheDir() string

[magical]

It sounds like we should do this, as os.UserCacheDir. Per discussion with @bradfitz, let's run with $HOME (not using os/user) until we know a compelling reason to need the fallback.

If this goes in as os.UserCacheDir, then isn't it true that it can never fall back on os/user because os cannot depend on os/user?

[bradfitz]

If this goes in as os.UserCacheDir, then isn't it true that it can never fall back on os/user because os cannot depend on os/user?

There are shenanigans we can do with internal packages to make it work later if we wanted.

[magical]

There are shenanigans we can do with internal packages to make it work later if we wanted.

I assume you mean something like creating an internal/os/user package that both os and os/user depend on.

Suppose you did that. On unix, os/user can get the user data one of two ways

1. Using a C standard library call. Russ objected to cgo earlier, so i assume this is out.
2. Reading /etc/password. This requires opening a file, which requires... os. So os still can't depend on internal/os/user because it creates a dependency loop. Now you either need to pull os.File into an internal package, or rewrite os/user using raw syscalls, or something else.

You're also basically pulling most of the os/user functionality into os, and I assume that there was a good reason to keep them separate in the first place.

It's probably not impossible to work around all these issues, but it seems like an awful lot of effort for something very small.

I don't really care either way whether UserCacheDir falls back on os/user or not (and Russ makes a good point that the spec doesn't say it has to). I just don't think you can defer the decision if you put it in os.

[bradfitz]

Well, cgo could be done if needed. And regarding 2), we could e.g. have the os package tell the internal package how to open files, passing an implementation of func (name string) (io.ReadCloser, error) in some init block. And then the os/user and/or internal package would use that to read /etc/password.

So while I'm not too worried about the trickery we could play to make it work later if we needed the current user, I'm also not worried where this function lives. I'll defer to Russ who seems content with package os.

[magical]

As you will.

[nightlyone]

Why is it implemented now without returning an error?

Chaining is impossible anyway, since the return value must be checked for the in-band error condition of empty string. So might as well return a real error value where error conditions for not being able to reduce a cache directory can be communicated, so the user/developer/admin can fix them.

With the currently implemented API the caller needs to re-implement the same functionality again with error handling when he receives an empty string to be able to tell the user how he can fix the situation.

[mvdan]

@nightlyone what about non-empty dir path, but the actual dir does not exist? Would the func also return an error in that case?

[mvdan]

@bradfitz @rsc did you see @nightlyone's comment above? If we want to change the signature of this function, we should do that before the final 1.11 release.

[mvdan]

Scratch my comment above; I just realised the error return parameter was added later in 50bd1c4.