Related: #6197

The error is especially unhelpful if there is only one package:

$ cabal build
TODO: add support for multiple packages in a directory.  Got
BNFC-2.9.4
BNFC-2.9.4

CallStack (from HasCallStack):
  error, called at src/Distribution/Client/ProjectOrchestration.hs:579:9 in cabal-install-3.7.0.0-inplace:Distribution.Client.ProjectOrchestration

$  find . -name "*.cabal"
./BNFC.cabal

$ cat cabal.project.local
packages: BNFC.cabal

package *
  ghc-options: -fwrite-ide-info

Removing cabal.project.local makes the error go away. What is going on here?

This is a reproducer (for at least 3.0, 3.2, 3.4, 3.6.2, master):

#!/bin/sh

cd $(mktemp -d)
${CABAL:-cabal} init -n --exe --package-name=IExistOnlyOnce
cat > cabal.project.local <<EOF
packages: IExistOnlyOnce.cabal
package *
  ghc-options: -Wall
EOF
${CABAL:-cabal} build

Error:

...
TODO: add support for multiple packages in a directory.  Got
IExistOnlyOnce-0.1.0.0
IExistOnlyOnce-0.1.0.0
...

Not reproducible in 2.4.1.

The issue posted before #6197 also mentions that cabal.project.local behaves weirdly.

Oh, there's another fun way to cause this bug: do this:

cabal.project:

packages: .

cabal.project.local:

packages: .

Surprisingly, I've hit this multiple times by accident.

The whole approach how cabal.project files are tracked and handled need to be redesigned with good error messages in mind. The PR #7396 only fixes a single symptom, I believe we need to change the Semigroup instance of project files to include more provenance information.

Would love to work on it, but I am a little overextended at the moment. If someone else wants to work on it, I'd be very happy to explain my thoughts in more detail and pair a bit to show what I think needs to be fixed.

Oh, there's another fun way to cause this bug

Oh yes, I got stumped by this a couple of ears ago. Perhaps in a variant, where both places have ../.