Should existence of $XDG_CONFIG_HOME/cabal/config override existence of $HOME/.cabal?

[athas]

Somewhere in #7386 it was brought up that the current backwards compatibility mode, where the mere presence of a ~/.cabal directory disables the XDG behaviour, is fragile because older tools may accidentally create this directory, which will cause subsequence cabal invocations to change their behaviour. It was suggested to add another wrinkle:

• If $XDG_CONFIG_HOME/cabal/config exists, then XDG behaviour is enabled (and this config file used), regardless of whether ~/.cabal (and ~/.cabal/config) exists.

The idea here is that it is unlikely for $XDG_CONFIG_HOME/cabal/config to be created accidentally, while ~/.cabal can more easily be created accidentally by older tools that are not aware of the XDG behaviour.

Opinions? It would not be particularly difficult to implement; just another case in the existing compatibility functions.

[mouse07410]

I say - absolutely not.

idea here is that it is unlikely for $XDG_CONFIG_HOME/cabal/config to be created accidentally

Strongly disagree. As likely to be "accidentally" created by newer XDG-aware tools, as the old config likely to be created by the old/current tools.

And in any case, make damn sure that CABAL_DIR overrules all of those.

[athas]

CABAL_DIR should always overrule anything, as that's never going to be set by accident.

I think it is is unlikely that new tools will create a cabal config file (why should they?) the way older tools might create a ~/.cabal directory to put something else in there (or maybe just by accident when they're looking for something in there).

[mouse07410]

CABAL_DIR should always overrule anything, as that's never going to be set by accident.

Thank you!

I think it is is unlikely that new tools will create a cabal config file (why should they?) the way older tools might create a ~/.cabal directory to put something else in there

I say - if there are tools on the system that insist on using the old convention, then you ought to honor it as well. Otherwise - I worker want to be the one who had to untangle the mess of done stuff going to the old and some - to the new...

or maybe just by accident when they're looking for something in there

Impossible. Looking fur something (as opposed to creating something new) in a non-existing directory always returns an error, and does not create a directory. What have you the reason to assume otherwise???

[Mikolaj]

Perhaps let's just see how it's used in the wild and what the user-reported real use cases and pitfalls are. If users are motivated enough to report them, I think it's worth fixing according to their report.

[andreasabel]

Perhaps let's just see how it's used in the wild and what the user-reported real use cases and pitfalls are.

Now we have some:

• Output cabal-store: Use XDG directory structure for cabal 3.10? actions#210
• Consider using XDG directory structure for cabal in CI #8855

[ulysses4ever]

One issue popped up because the idea presented in this thread wasn't implemented in 3.10:

• cabal update is not run? actions#203

This is now featured in the release announcement thread.

On the last cabal meeting this week, people seemed to agree that:

1. Implementing this idea in 3.10.2.0 is desirable.
2. If two cabal directories are found, cabal should issue a warning describing the situation, and making suggestion to the user to remove either of directories manually and do cabal update manually.

@athas would you be interested in working on this?

[athas]

Sure, I can take a shot at it. The (2) warning cannot be specific to cabal update, though, since the code looking for the directory is generic.

Incidentally, my own protection from this issue is to create a ~/.cabal file, which new cabals will ignore but will cause old cabals to crash. This is less viable in CI setups though, where it seems the issue is most common.

[ulysses4ever]

The (2) warning cannot be specific to cabal update

It doesn't have to be, I think. I think it's fine for every command to complain about it because it's an undesirable state of things.

As for workarounds: several has been proposed but the idea of this approach is that it should work more reliably for people who don't necessarily understand the problem and are not aware of any workarounds.

[ulysses4ever]

Another option discussed on IRC is to have an environment variable indicating whether the user wants XDG or not; if the var is not set, we always use ~/.cabal.

Pros:

• it’s very common; e.g. it’s what stack and ghcup do;
• no funny defaults and over complicated checks

Cons:

• rather significant change from what we have in 3.10.1
• we don’t have many users actually using it.

I think the pros outweigh the cons. Not many people care about XDG, and those who care will be able to get it (and become our testers). Vast majority won’t notice anything and will be happy in their ignorance; that’s much better than what we ended up having with 3.10.1 when people not caring about XDG get into trouble because of it.

Opinions?

[mouse07410]

@ulysses4ever I support your idea.

[Mikolaj]

I will take any reasonable solution as long as it's quick, so that we can release 3.10.2.0 soon.

[athas]

I am not in favour of hiding XDG behaviour behind an environment variable. It would be a mess if every program required that.

[ulysses4ever]

@hasufell maybe I wasn't convincing enough presenting your idea about env var for XDG (#8577 (comment)). Do you want to add anything?

@andreasabel it would be interesting to know your opinion also.

[hasufell]

I am not in favour of hiding XDG behaviour behind an environment variable. It would be a mess if every program required that.

GHCup does, stack does.

XDG is already a mess. It took a couple of decades to support binary directory and now it's defined without a way to change it, breaking configurability, which was the entire point of XDG.

I don't see a good argument why we should disrupt CI systems or the majority of users who don't care about XDG.

It will never be consistently supported by all tools anyway. And it has serious drawbacks too (sharing of bindir is one).

[athas]

Why is it that XDG support disrupts CI systems? I can see that caches built for pre-XDG cabal may interact poorly with XDG cabal, but that sounds like an issue that will resolve itself quickly, as CI caches don't tend to live that long.

Normal users will probably not be disrupted much. The only case I can think of where confusion occurs if if you do a cabal update with XDG-cabal, then copy in an older/stale/incomplete ~/.cabal from somewhere else. This can happen in CI systems, but I find it unlikely outside of them. Some users may be confused not to find a ~/.cabal at all, of course.

[mouse07410]

+1 to Julian.

If env var is set - it becomes the ultimate authority.

And in general, the one thing we should want to avoid is ambiguity.

[athas]

We already have one of those: if CABAL_DIR is set, it is the ultimate authority.

[hasufell]

We already have one of those: if CABAL_DIR is set, it is the ultimate authority.

Sure. I can make ghcup set it by default to avoid some of the fallout.

[Mikolaj]

@hasufell: I'm in favour, regardless of whether it's a good default long term, because here we have a short term emergency and no resources to handle it the way it should be handled (e.g., communicate with all CI, devenv and tool maintainers and test with all passively maintained tools ourselves and fix as needed).

[Mikolaj]

The PR is now merged and backported. Shall we close the ticket?

[ulysses4ever]

Indeed. Excited to see how it pans out in practice!

[hasufell]

Why is it that XDG support disrupts CI systems?

haskell-actions/setup#62