coursier uses two different concepts of $HOME, then crashes by failing to relativize paths

[warpfork]

I've run into an interesting bug in my environment, where while on a linux machine, I am setting the $HOME variable (as a (very) poor-man's sandbox), and this breaks coursier's fetching and caching.

In the log below, the prevailing environment has HOME=/work/ORGNAME/home/. However, if something were to parse my /etc/passwd records for my $USER or uid, it would find /home/USERNAME/. We see both paths appear in the log below, which seems like a bug. (And also, results in an exception being thrown.)

INFO: Repository unpinned_maven instantiated at:
  /work/ORGNAME/repos/monorepo/WORKSPACE:216:14: in <toplevel>
  /work/ORGNAME/home/.cache/bazel/_bazel_hash/5008519db711c0d2856b19cdd0b37c03/external/rules_jvm_external/private/rules/maven_install.bzl:104:19: in maven_install
Repository rule coursier_fetch defined at:
  /work/ORGNAME/home/.cache/bazel/_bazel_hash/5008519db711c0d2856b19cdd0b37c03/external/rules_jvm_external/coursier.bzl:1211:33: in <toplevel>
ERROR: An error occurred during the fetch of repository 'unpinned_maven':
   Traceback (most recent call last):
	File "/work/ORGNAME/home/.cache/bazel/_bazel_hash/5008519db711c0d2856b19cdd0b37c03/external/rules_jvm_external/coursier.bzl", line 902, column 84, in _coursier_fetch_impl
		artifact.update({"file": _relativize_and_symlink_file_in_coursier_cache(repository_ctx, artifact["file"])})
	File "/work/ORGNAME/home/.cache/bazel/_bazel_hash/5008519db711c0d2856b19cdd0b37c03/external/rules_jvm_external/coursier.bzl", line 199, column 13, in _relativize_and_symlink_file_in_coursier_cache
		fail("Error while trying to parse the path of file in the coursier cache: " + absolute_path)
Error in fail: Error while trying to parse the path of file in the coursier cache: /home/USERNAME/.cache/coursier/v1/https/maven.scijava.org/content/groups/public/com/github/sbridges/object-inspector/object-inspector/0.1/object-inspector-0.1.jar
ERROR: /work/ORGNAME/repos/monorepo/WORKSPACE:216:14: fetching coursier_fetch rule //external:unpinned_maven: Traceback (most recent call last):
	File "/work/ORGNAME/home/.cache/bazel/_bazel_hash/5008519db711c0d2856b19cdd0b37c03/external/rules_jvm_external/coursier.bzl", line 902, column 84, in _coursier_fetch_impl
		artifact.update({"file": _relativize_and_symlink_file_in_coursier_cache(repository_ctx, artifact["file"])})
	File "/work/ORGNAME/home/.cache/bazel/_bazel_hash/5008519db711c0d2856b19cdd0b37c03/external/rules_jvm_external/coursier.bzl", line 199, column 13, in _relativize_and_symlink_file_in_coursier_cache
		fail("Error while trying to parse the path of file in the coursier cache: " + absolute_path)
Error in fail: Error while trying to parse the path of file in the coursier cache: /home/USERNAME/.cache/coursier/v1/https/maven.scijava.org/content/groups/public/com/github/sbridges/object-inspector/object-inspector/0.1/object-inspector-0.1.jar
ERROR: Error while trying to parse the path of file in the coursier cache: /home/USERNAME/.cache/coursier/v1/https/maven.scijava.org/content/groups/public/com/github/sbridges/object-inspector/object-inspector/0.1/object-inspector-0.1.jar
INFO: Elapsed time: 120.563s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (1 packages loaded)

I think the correct behavior is almost certainly to honor $HOME, but at the very least, it's definitely a bug to be using two different inconsistent mechanisms to determine the user's homedir and cache paths.

I've been able to work around this by simply... not setting $HOME to a distinct value, and running this particular process again. (In my context, fortunately, that's possible, because this process runs purely for its side-effects, and not during our main build flow.) This does also confirm from another angle that the $HOME environment variable is the provoker of the problem. I'd still like to see a fix upstream though, both because the bug is generally surprising, and because this workaround does also result in my having two different whole bazel caches, which is... not desirable. :)

This was observed on rules_jvm_external 6.0, used in bazel 6.4.0.

[cheister]

All of the rules_jvm_external code uses $HOME, it looks like coursier itself may not using be $HOME when it is creating the file paths for the artifacts though, possibly because of this code https://github.com/coursier/coursier/blob/v2.1.8/modules/paths/src/main/java/coursier/paths/CoursierPaths.java#L61 which invokes https://github.com/coursier/coursier/blob/v2.1.8/modules/paths/src/main/java/coursier/paths/CoursierPaths.java#L107 to get directory paths.

If you run REPIN=1 bazel run @maven//:pin instead of bazel run @unpinned_maven//:pin do you get the same problem?