make cabal less chatty w.r.t. project files in use

[ulysses4ever]

fix #10885

After #10507, cabal prints out what project files are in use on every run.
This looked too noisy for some users (#10885). In this patch, we implement a more nuanced
strategy: print out this info only when cabal is run below the root project directory.
As before, you can get this information uncoditionally if run in the verbose mode.

Bonus: we now also print the porject root directory along with the file names.
Before, we only printed, say, cabal.project, but it wasn't clear where this file is
coming from (can be enywhere up the directory tree).
The change tries to avoid confusion when cabal picks up stray project files in
ancestor directories, see discussion in #7930.

The diff in tests is big but it should mostly just undo the changes from #10507.

Manual QA

• Create a simple package, e.g. cabal init -nm --lib.
• Create a project file, e.g. echo 'packages: .' > cabal.project
• Run cabal build all --dry -- expect NO message about project files.
• cd src and run cabal again just as in the previous step -- expect a message about cabal.project.

---

Template Α: This PR modifies behaviour or interface

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.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[Mikolaj]

Are you still seeing the problems in the CI? As in

I'm seeing weird (seemingly) unrelated test failures in CI (just several) on my draft PR and can't explain them.
They all seem to start with output:


+ /usr/bin/git ls-files --cached --modified


so that's a new line in the output, right? No idea where it comes from...

Here's an example run https://github.com/haskell/cabal/actions/runs/15117706253/job/42492471019

Would appreciate any insights...

[ulysses4ever]

@Mikolaj yes, that's why the pipelines are currently failing I believe

[Mikolaj]

I don't think this + indicates an error, because it's not in the context of "Actual output differs from expected:" and there's no patch syntax (---, +++, @@ -1,7 +1,5 @@, etc.). See this real error from the same file for comparison:

Actual output differs from expected:

stderr:
--- /tmp/cabal-testsuite-154925/cabal.yes.dist/cabal.yes.out.normalized	2025-05-19 16:23:19.039827000 +0000
+++ /tmp/cabal-testsuite-154925/cabal.yes.dist/cabal.yes.comp.out.normalized	2025-05-19 16:23:19.039827000 +0000
@@ -1,7 +1,5 @@
 # cabal clean
 # cabal v2-repl
-Configuration is affected by the following files:
-- cabal.project
 Resolving dependencies...
 Build profile: -w ghc-<GHCVER> -O1
 In order, the following will be built:

*** unexpected failure for PackageTests/MultiRepl/CustomSetupKeepTempFiles/cabal.test.hs

[ulysses4ever]

Oh my, I had a feeling I lost my way in the output... I wonder if in the future we could try to avoid generating +'s like the one that confused me.

The actual failure is expected and will be fixed. The reason it wasn't fixed before is that when I ran the testsuite locally --accept'ing the necessary changes, this test failed with an exception in ProjectaOrchestration.hs. This is a discrepancy between my local setup and CI that probably deserves a separate ticket but let's not get bogged down by this.

Thanks for unlocking me! Now I can probably finish fixing tests at least.

[ulysses4ever]

2025-05-29T15:32:41.9907347Z PackageTests/JS/JSPPOptions/other-arch.test.hs                                                                    FAIL (2.94s)

I don't see this test in my tree — is it a ghost?

[geekosaur]

Seems to be from https://github.com/haskell/cabal/pull/10722/files#diff-5b2c8500c79636c2f408a166261b24ddbdf12e9aaa31c75b0fb50f8a954188f4 ?

[ulysses4ever]

@geekosaur

Seems to be from https://github.com/haskell/cabal/pull/10722/files#diff-5b2c8500c79636c2f408a166261b24ddbdf12e9aaa31c75b0fb50f8a954188f4 ?

Exactly: that one isn't merged yet, so there shouldn't be tests from there on my branch...

---

I'm having trouble understanding this:

Actual output differs from expected:

stderr:
--- /private/var/folders/w5/_8wgjw3j5cg6mgrth3s2kg9m0000gn/T/cabal-testsuite-73838/cabal.dist/cabal.out.normalized	2025-05-29 18:38:06
+++ /private/var/folders/w5/_8wgjw3j5cg6mgrth3s2kg9m0000gn/T/cabal-testsuite-73838/cabal.dist/cabal.comp.out.normalized	2025-05-29 18:38:06
@@ -11,7 +11,7 @@
 Running 1 test suites...
 Test suite test: RUNNING...
 Test suite test: PASS
-Test suite logged to: cabal.dist/work/./dist/build/<ARCH>/ghc-<GHCVER>/plain-0.1.0.0/test/plain-0.1.0.0-test.log
-Package coverage report written to cabal.dist/work/./dist/build/<ARCH>/ghc-<GHCVER>/plain-0.1.0.0/hpc/vanilla/html/hpc_index.html
+Test suite logged to: <ROOT>/cabal.dist/work/./dist/build/<ARCH>/ghc-<GHCVER>/plain-0.1.0.0/test/plain-0.1.0.0-test.log
+Package coverage report written to <ROOT>/cabal.dist/work/./dist/build/<ARCH>/ghc-<GHCVER>/plain-0.1.0.0/hpc/vanilla/html/hpc_index.html
 1 of 1 test suites (1 of 1 test cases) passed.
-Package coverage report written to cabal.dist/work/./dist/build/<ARCH>/ghc-<GHCVER>/plain-0.1.0.0/hpc/vanilla/html/hpc_index.html
+Package coverage report written to <ROOT>/cabal.dist/work/./dist/build/<ARCH>/ghc-<GHCVER>/plain-0.1.0.0/hpc/vanilla/html/hpc_index.html

*** unexpected failure for PackageTests/CustomTestCoverage/cabal.test.hs

---

@Bodigrim thanks for your comments. I'll incorporate them when/if I finish my fight with the test suite. Currently, it's not clear who will come out as a victor, I or it...

[geekosaur]

I've never really understood all the normalization stuff, tbh. And I think I poked at it once and found it a bit hacky.

[ulysses4ever]

Okay, test suite issues aside, there's an actual technical question: if we want to print project files out only when cabal is run from a directory below the project root, we need to be able to determine, somehow, that we are not in the project root. How?

My first idea was to look at the path to project files, 'cause I thought their paths would be stored relative to CWD but that's of course not the case --- their paths are relative to the project root (it makes sense: otherwise we'd have to reconfigure everytime we change directory we run cabal from).

So, I'm currently looking for ideas on how to tell that cabal is run not from the project root.

[ulysses4ever]

all right, looks like distProjectRootDirectory /= cwd should work.

I understand this no longer applies after the other PR was merged. Please correct me if not.

[Mikolaj]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[philderbeast]

If @ulysses4ever agrees to rebase on top of #10688, then let's indeed speed up its merge.

#10684 has the fix for the duplicate "Configuration is affected by" notices so ideally that would go in first so we'd see its fix in the test output changes.

[philderbeast]

Sorry for the delay @ulysses4ever.

[ulysses4ever]

no problem @philderbeast!

[geekosaur]

I think I've mentioned this before (and I know this was a rebase, not new commits) but fixup! and friends will soon be useless: Mergify is disabling autosquash and their announcement implied that they consider it a bad idea. (They didn't explain why, and I don't recall git itself warning about their use. I also don't see a blog entry about it, or a web link in the newsletter they sent me.)

👋 Bye autosquash, you won’t be missed
Autosquash is now disabled by default and will be deprecated soon.
You probably weren't using it. If you were… let's be honest, you probably shouldn't be.

[ulysses4ever]

@geekosaur thanks, quite true. This is more of a convention for me rather than a tool.

[ulysses4ever]

@geekosaur there are hidden perks that "fixup!" brings, e.g. Magit comments out these messages when doing squash locally and forming the resulting commit message

[ulysses4ever]

@mergify refresh

[mergify]

refresh

✅ Pull request refreshed