Closed athas closed 1 year ago
Thanks! Can you also link to the upstream code that implements this in the comment for reference?
This also shows that we should respect the CABAL_DIR
environment variable, but we can also do that in a separate change, as we weren't even respecting it in the first place.
Link added.
The Right Solution is perhaps to depend on cabal
to use exactly the same logic. However, cabal2nix got away with not doing exactly what cabal
does so far (in particular, not respecting CABAL_CONFIG
or CABAL_DIR
), so it probably does not matter in practice.
Seems like cabal-install has made our lives harder than it should be – namely you can also configure arbitrary location for the package db location. What's worse this is apparently rendered into the configuration file by default, so even if people move their config to xdg paths, it may still show up under ~/.cabal
.
Not quite sure yet how to proceed – we'll want to avoid depending on cabal-install
I think, since it is quite the dependency. One nice thing is that we support a wide range of Cabal
libraries, but supporting a wide range of cabal-install
is likely very painful.
The issue with paths being stored in the cabal config file is not new. It's been like that for a while - maybe forever. This PR does not make the situation worse.
True, but it'll be more likely to be a problem now. In any case that we'll have to prefer ~/.cabal
anyways will get us out of 90% of the issues hopefully.
For anything else I'll implement CABAL_DIR
and people will have to work around it manually.
From 3.10.1.0 onwards, cabal-install uses XDG directories to store its state and cache components. cabal2nix expects to find the Hackage tarball in ~/.cabal, where it may no longer be located.
This commit changes cabal2nix to look in ~/.cabal if that directory exists (which matches the behaviour of cabal-install itself), but otherwise looks in the appropriate XDG directory.