Using ~ in `remote-repo-cache` crashes `cabal update` and isn't recognised by `cabal build`

[j-mie6]

Describe the bug Having a cabal.project file with remote-repo-cache: ~/.cache/cabal/my-packages breaks cabal update, with the following error:

cabal update
Downloading the latest package list from hackage.haskell.org
~/.cache/cabal/my-packages/hackage.haskell.org/01-index.timestamp: withFile: does not exist (No such file or directory)

specifying as /home/jamie/.cache/cabal/my-packages works just fine with cabal update. Having done this, switching back to ~/ instead of /home/jamie/ produces the following for cabal build:

Error: [Cabal-7160]
The package list for 'hackage.haskell.org' does not exist. Run 'cabal update' to download it.

This seems to affect cabal versions from at least as far back as 3.10.1.0, I also tested with 3.10.3.0 and 3.12.1.0 with the same issue.

[j-mie6]

the same applies, it seems, for the --local-repo-cache flag too.

[geekosaur]

~ is a shell-ism, and programs have to do extra work to support it. At which point the question becomes whether to also support other shell-isms (~user, $envar, etc.). Most programs punt on it, aside from e.g. editors and such.

[j-mie6]

In which case, there needs to be some way of specifying the home directory in the configuration here! But presumably, whatever is doing the file I/O code-side should just be using native APIs that do understand ~, no? I'm pretty sure I can use ~ in regular file I/O right (if not I certainly can in other languages!)

[geekosaur]

Some languages support it (e.g. Perl), others do not (e.g. C/C++, Java). There is no native API that supports it, except in convenience-oriented languages that specifically support shell-isms. (Try something like cat ~/foo vs. cat '~/foo'.)

[j-mie6]

That's true, but in Java, say, you can use System.getProperty("user.home") to fetch it, perhaps if cabal is running in a UNIX environment it can take a leading ~ on a path and lookup the appropriate home?