Display within which cabal.project we build

[mgajda]

Describe the bug

The cabal behaves differently depending whether any of the ancestor directories has cabal.project or not. Since we should not demand the user to only ever test builds within a fresh /tmp directory, and large builds may easily have multiple cabal.projects, it would be nice to warn the user which cabal.project we use, or that there is none used in this case.

To Reproduce

Steps to reproduce the behavior:

$ git clone https://gitlab.com/migamake/homplexity
$ cabal new-build
$ cabal sdist
$ cd dist-newstyle/sdist
$ tar xzf homplexity-*.tar.gz
$ echo "Let's test the build...."
$ cd homplexity-*
$ cabal new-build

This build breaks.

If we do:

$ mkdir /tmp/homplexity-test
$ tar xzf $MYPATH/homplexity*.tar.gz
$ cabal new-build

We get a correct build.

The only difference is absence of the cabal.project file in the second case.

Expected behavior

cabal new-build should tell why its behaviour differs by indicating which cabal.project is used, or printing no cabal project.

System information

• any
• cabal 3.4.1,0
• ghc version -- does not matter

[ffaf1]

Do you propose a Using cabal.project at ~/some/folder/cabal.project before Resolving dependencies...?

[ulysses4ever]

Yes, very close discussion is in #7930. By all means please do this. I expect it to be a 1-line change.

[pigsinablanket]

If you pass in --verbose=2, cabal will specify which cabal.project are being used. https://github.com/haskell/cabal/blob/master/cabal-install/src/Distribution/Client/ProjectPlanning.hs#L344

    info verbosity
      $ unlines
      $ ("this build was affected by the following (project) config files:" :)
      $ [ "- " ++ path
        | Explicit path <- Set.toList $ projectConfigProvenance projectConfig
        ]

Should this be output by default?

[ulysses4ever]

@pigsinablanket brilliant! It should be a matter of changing info to notice in that snippet. Do you want to submit a PR? I expect a little annoyance with updating the testsuite, but it should be easy solve by supplying --accept when running the testsuite. This means that you have to run it locally though (as opposed to simply edit the line in GitHub web interface and be done with it).

[ulysses4ever]

3.10 is quickly approaching, and I hope to have this in it, so I add it to the project…

[pigsinablanket]

@pigsinablanket brilliant! It should be a matter of changing info to notice in that snippet. Do you want to submit a PR? I expect a little annoyance with updating the testsuite, but it should be easy solve by supplying --accept when running the testsuite. This means that you have to run it locally though (as opposed to simply edit the line in GitHub web interface and be done with it).

@ulysses4ever Running the tests locally with --accept worked, except in some tests it used the fully qualified path for the cabal.project instead of <ROOT> as it generates in other tests. Is there a reason the normalizer is not resolving the path?

Updating the cabal.out to use <ROOT> after running the testsuite with --accept didn't work.

 this build was affected by the following (project) config files:
-- <ROOT>/cabal.project
+- /home/daniel/git/cabal/cabal.project

[ulysses4ever]

@pigsinablanket interesting. I wouldn't expect manual editing of the result of --accept to work. Could you perhaps commit the result as is, submit the PR, and see what CI has to say about it, please?

Also, while we're at it, may I propose a slight rewording of the message? My preference, instead of

this build was affected by the following (project) config files:

to have

This build is affected by the following project file(s):

[ulysses4ever]

("result as is" meaning: commit exactly what --accept did)

[andreasabel]

This isn't just a one-line change, as demonstrated by PR #8617, so I am removing the respective label. What is left to do here is to only print the info when cabal is actually building something, not on side commands like cabal update, cabal info, or on installation from remote (cabal install --ignore-project Foo).

[juhp]

I am afraid I honestly feel the current behavior (including the error message) is pretty terrible...

cabal build should not trip over just because there is a cabal.project in some upper directory. Heavens cabal build doesn't even work in eg a src/ subdir anyway, shrug. What is the use-case for the current behaviour actually?

ie if cabal build is run in a non-project package dir, couldn't it just ignore parent cabal.project?