Ignore ~/.cabal if $XDG_CONFIG_HOME/cabal/config exists.

[athas]

This is a draft implementation of #8577.

There is one flaw in this implementation: the warning is printed many times, and with non-configurable verbosity. Changing that would require one of:

1. Significant refactoring of how getDefaultDir is called, which has non-local implications.
2. Doing the warning somewhere else (e.g. in Main.hs).

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.

Please also shortly describe how you tested your change. Bonus points for added tests!

[athas]

It now warns only when loadConfig is called, but for some commands (e.g. cabal install) that is still twice.

[ulysses4ever]

It’s my understanding that there’s no way we can test that it does the right thing, is there?

[ulysses4ever]

I’m not worried about repetitive warnings: it won’t happen too often, and really the user should make sure that there’s only one thing exists.

[athas]

It’s my understanding that there’s no way we can test that it does the right thing, is there?

In principle it is possible to do so in an ad-hoc manner (after all, I tested it manually), but I don't know whether cabal's test suite is set up to make it easy.

[Mikolaj]

What's the status here? Let me add a needs-review label in case it's ready for review...

[athas]

I don't remember anything left to do here. There are no tests, though.

[Kleidukos]

@athas If you could write down some instructions for QA testers so that they can manually check your patch, that would be grand. :)

[athas]

Sure. There are the following situations to test, based on which files and directories exist. Their contents do not matter.

1. Neither $HOME/.cabal nor $HOME/.config/cabal/config exist. In this case cabal help should print $HOME/.config/cabal/config on the second-to-last line.
2. $HOME/.cabal exists as a directory and $HOME/.config/cabal/config does not exist. cabal help should print $HOME/.config/cabal/config on the second-to-last line (or last line if $HOME/.cabal/config actually exists).
3. $HOME/.cabal exists as a directory but $HOME/.config/cabal/config also exists. cabal help should print $HOME/.config/cabal/config on the last line.
4. $HOME/.cabal does not exist but $HOME/.config/cabal/config exists. cabal help should print $HOME/.config/cabal/config on the last line.

[Mikolaj]

@athas: it's normally PR author's role, but let me set the label in the interest of merging this, before CI breaks or something. :) This will also unblock QA, which happens after the merge.

[Mikolaj]

@mergify backport 3.10

[mergify]

backport 3.10

✅ Backports have been created

• #8971 Ignore ~/.cabal if $XDG_CONFIG_HOME/cabal/config exists. (backport #8877) has been created for branch 3.10

[Mikolaj]

@mergify unqueue

[mergify]

unqueue

☑️ The pull request is not queued

[Mikolaj]

@mergify queue

[mergify]

queue

🛑 The pull request has been removed from the queue

Pull request #8877 has been dequeued due to failing checks or checks timeout.

You can take a look at Queue: Embarked in merge train check runs for more details.

In case of a failure due to a flaky test, you should first retrigger the CI.
Then, re-embark the pull request into the merge queue by posting the comment
@mergifyio refresh on the pull request.

[ulysses4ever]

@mergify refresh

[mergify]

refresh

✅ Pull request refreshed

[ulysses4ever]

There's a funny Mergify failure here :

The merge queue pull request can't be updated
Details:

    Base branch update has failed

    refusing to allow a GitHub App to create or update workflow .github/workflows/quick-jobs.yml without workflows permission
    err-code: CDDDA

I don't understand why Mergify (apparently) tries to modify the workflow file...

[ulysses4ever]

Googling gives this: Mergifyio/mergify#5055 supposedly resolved by this comment:

This is a GitHub App permission problem. If you log into your Mergify dashboard you should see a message requesting you to update the permission for the app.

I don't see anything like that in the dashboard but on one of the tabs it says that I should be an GH Org admin to fiddle with "Application keys", which I'm not sure whether it's related or not. https://dashboard.mergify.com/github/haskell/application-keys

[athas]

Is something more expected of me? It's not that I would mind writing automated tests, but someone gave me the impression that it would not be easy to fit into cabal's current test infrastructure. I'm fine with adding some more furniture, but I don't currently have the time to rework the plumbing.

[Mikolaj]

@athas: I wasn't the reviewer, so I don't know, but this PR is certainly ready to be merged and 3.10.2.0 release is blocked by it, so we are currently most of all fighting the random technical obstacles to that effect. Thank you for asking, though. :)

[Mikolaj]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[ulysses4ever]

@athas I think your job is done here, thanks a lot! Let's keep in touch: XDG is a rather fundamental change, and I expect more questions will need to be discussed in the future.

[jgotoh]

Manual QA succeeded for the provided steps, if anyone is interested here is the console output:
https://gist.github.com/jgotoh/1626aba91f742b74629c689a9af827d6

[ulysses4ever]

Great! 🎉

[Mikolaj]

Thanks, this works for me in the semi-wild with cabal 3.10.2.0-alpha1. I had no idea I have cabal configs in both locations and it detected it. Here's my battle report from the Matrix channel:

---

FYI, I'm dog-fooding the centos7 flavour of cabal 3.10.2.0-alpha1 from https://gitlab.haskell.org/haskell/cabal/-/jobs/1651797/artifacts/browse/out/
so far, so good, it builds stuff fine (though there is a slight inconsistency in the message below, as it mentions a directory first and a (config) file in an analogous directory second)

123456789~/r/horde-ad$ cabal build horde-ad-simplified --enable-optimization 
Warning: Both /home/mikolaj/.cabal and /home/mikolaj/.config/cabal/config
exist - ignoring the former.
It is advisable to remove one of them. In that case, we will use the remaining
one by default (unless '$CABAL_DIR' is explicitly set).
Warning: Both /home/mikolaj/.cabal and /home/mikolaj/.config/cabal/config
exist - ignoring the former.
It is advisable to remove one of them. In that case, we will use the remaining
one by default (unless '$CABAL_DIR' is explicitly set).

(and the message is repeated twice, but that's probably unavoidable; IDK)
in any case, it detected my duplicated cabal config and warned me, so it prevents real user problems

[Kleidukos]

We have the option of mentioning $CABAL_CONFIG instead.

We can also link to the manual: https://cabal.readthedocs.io/en/3.10/config.html#configuration-file-discovery

[Kleidukos]

@Mikolaj Do you think this warrants a patch?

[Mikolaj]

If I'm wrong and the message duplication is easy to fix, then a patch would be helpful. Then we could also make the mentions of directory /home/mikolaj/.cabal vs file /home/mikolaj/.config/cabal/config consistent and mention $CABAL_CONFIG instead or in addition to $CABAL_DIR (I'm happily ignorant about what they do).

I think there's absolutely no rush. The problems are minor and the changes will be backward compatible, so they don't need to be included this release. But I may be misunderstanding any of the above.