cabal-install-parsers: support XDG

[fgaz]

(From haskell-hvr/cabal-plan#92)

cabal-install 3.10 uses XDG paths. For example in my system the config file is ~/.config/cabal/config and the store is ~/.local/state/cabal/store. Cabal.Config:readConfig does not return the correct paths.

To know whether to enable XDG support, cabal-install first looks at $CABAL_DIR. If that variable is set, everything will be in there, as before. Otherwise, it checks whether $XDG_CONFIG_HOME/cabal and ~/.cabal exist, and enables or disables XDG support. If both are present, ~/.cabal takes priority, but that's considered a mistake and likely to change: haskell/cabal#8577

You can find a list of paths here and here. See also the relevant functions from the directory package.

In the future, something like this could be used: haskell/cabal#8879

[phadej]

TBH, this situations just sucks, so I'd suggest to define CABAL_CONFIG environment variable and have your cabal config files specify the pathes, then you won't rely on any implicit, which change between cabal-install versions.

but that's considered a mistake and likely to change:

That remark is specifically makes me don't want to do anything with this issue,. In fact, I'm even considering making cabal-install-parsers fail if CABAL_CONFIG environment variable is not set.

[hasufell]

TBH, this situations just sucks, so I'd suggest to define CABAL_CONFIG environment variable and have your cabal config files specify the pathes, then you won't rely on any implicit, which change between cabal-install versions.

but that's considered a mistake and likely to change:

That remark is specifically makes me don't want to do anything with this issue,. In fact, I'm even considering making cabal-install-parsers fail if CABAL_CONFIG environment variable is not set.

This response makes no sense.

cabal-install-parsers is broken. Whether you like the cabal config discovery logic or not.

So either fix it or stop providing this API so that you don't break other downstream tools like ghcup, which assume that dependencies are reasonably maintained.

[phadej]

stop providing this API

Am I forcing you to use it?

[hasufell]

stop providing this API

Am I forcing you to use it?

Are you deliberately providing broken API?

[phadej]

Are you deliberately providing broken API?

No. Just outdated, there is a known limitation.

The OP wrote

but that's considered a mistake and likely to change

are there still plans to change it? The 3.10 and 3.12 documentation seems to be the same.

---

@hasufell your tone is not motivating me to look into this issue any time soon.

[hasufell]

@hasufell your tone is not motivating me to look into this issue any time soon.

No one asked you to work on this. People can provide PRs.

Your response suggests:

• you don't care whether your packages are buggy
• you don't care whether your packages break Haskell core tooling
• you're not interested in collaboration

In that case that's a good reason to avoid any of your packages in the future.

[tchoutri]

@phadej If you proceed with it, how will you warn Haskell-CI users?

[phadej]

How will you warn Haskell-CI users?

About what? haskell-ci doesn't use cabal configuration file discovery.

[tchoutri]

Ok, so that would entirely be confined to direct users of cabal-install-parsers. Thank you for clarifying.