COURSIER_CACHE with relative path cause artifacts download into process sandbox folder

[chikei]

run COURSIER_CACHE=.cache/coursier ./mill -i clean and out/mill-build/runClasspath.json gives things like this:

"qref:v1:147a7190:/home/Chikei/repos/test/mill-debug/out/mill-no-server/8b3d4d59/sandbox/.cache/coursier/https/repo1.maven.org/maven2/com/lihaoyi/mill-moduledefs_2.13/0.11.1/mill-moduledefs_2.13-0.11.1.jar",

COURSIER_CACHE=.cache/coursier ./mill clean gives:

"qref:v1:147a7190:/home/Chikei/repos/test/mill-debug/out/mill-server/NTPC2Aizg2x0sjIWSk9BSuOjwzU=-1/sandbox/.cache/coursier/https/repo1.maven.org/maven2/com/lihaoyi/mill-moduledefs_2.13/0.11.1/mill-moduledefs_2.13-0.11.1.jar",

and there is no .cache/coursier under $PWD.
If run COURSIER_CACHE=$(PWD)/.cache/coursier ./mill -i clean, the artifacts are downloaded into $(PWD)/.cache/coursier and ref path in out/ point to $(PWD)/.cache/coursier

[lihaoyi]

I'm actually not sure what the best thing to do here is.

• Environment variables in general could refer to anything, so we can't just assume they are all paths. But passing relative paths to the Mill process is generally not going to work, since different Mill workers would have different working directories, as would different mill -i no-server processes.

• At the same time, being unable to reliably pass relative paths to environment variables is a huge footgun, beyond the specific Coursier behavior here. While libraries using OS-Lib may do the right thing (since you need to pass in the relative path base to os.Path(str, base) directly), there is a good chance they won't (e.g. if they rely on os.pwd which is the sandbox folder), and there'll be third-party libraries that use java.io/nio directly. And people expect when passing relative paths from the terminal that they will be relative to the current working directory, and not some weird sandbox folder

Not sure what we can do here other than documenting "please use $(PWD) when passing relative paths as env variables"