confusing error when missing `packages:`

[dmwit]

Describe the bug
If you forget to include a list of packages in your cabal.project, the error looks like this:

Warning: There are no packages or optional-packages in the project
Error: cabal: There is no <pkgname>.cabal package file or cabal.project file.
To build packages locally you need at minimum a <pkgname>.cabal file. You can
use 'cabal init' to create one.

For non-trivial projects you will also want a cabal.project file in the root
directory of your project. This file lists the packages in your project and
all other build configuration. See the Cabal user guide for full details.

The warning is spot-on, but the error is confusing, because it can be printed in exactly that way when there is both a <pkgname>.cabal file and a cabal.project file available. For people (like me) that tend to gloss over warnings if there's an error available, that's bad news.

To Reproduce

$ mkdir t
$ cd t
$ touch cabal.project
$ cabal v2-run t

Expected behavior
I'm not sure, but probably just rewriting the error is sufficient. Let it reflect more accurately what actual check is being done in the code.

System information

• cabal-install 3.8.1.0, Cabal 3.8.1.0
• ghc and OS versions are irrelevant I'm pretty sure, but just in case, Linux 5.14 and ghc 8.10.4

Additional context
This may be related to #8484, which describes the even-more-confusing error you get when you think "maybe t wasn't specific enough" and try cabal v2-run exe:t as your first debugging step.

[ulysses4ever]

Yes, very good description of what has been reported multiple times, I think. E.g. #4524. Let's hope someone picks it up!

[Kleidukos]

I'm interested in taking this ticket, but first I must ask: Any reason why we shouldn't default to packages: ./ if the stanza is absent?

[ulysses4ever]

"it's a good thing"

I think the default should be changed from empty to ./* when a project file is present.

[Kleidukos]

So do I. It's unnecessarily confusing.

[Mikolaj]

when any project file is being loaded and nothing else sets the value (I hope nothing else can set it, but I'm not 100% sure)

[Mikolaj]

being the indispensable voice of paranoia here

[andreabedini]

I am very sympathetic to the issue and I always found it annoying. (LPT you can add your configuration to cabal.project.local instead, and the default cabal.project will still be used)

My only problem with a packages: . as a default value is that I would not know how to specify no local packages (which I use e.g. to build and test hackage packages).

IIRC packages: is monoidal so once . is in there, you won't be able to remove it.

[ulysses4ever]

@andreabedini thanks a lot for opining!

My only problem with a packages: . as a default value is that I would not know how to specify no local packages (which I use e.g. to build and test hackage packages).

I'm afraid I don't quite get this particular bit. Could you show a sequence of commands that would fail under the new default? Starting from cabal get blah perhaps if we're talking trying out Hackage packages...

[andreabedini]

I feel a bit like https://xkcd.com/1172/ 😂 but I use this a lot to troubleshoot bounds and dependencies.

$ mkdir ~/test && cd ~/test
$ # Note the current directory is empty
$ echo "extra-packages: aeson" > cabal.project
$ cabal build aeson
Warning: There are no packages or optional-packages in the project
Resolving dependencies...
Build profile: -w ghc-9.2.8 -O1
In order, the following would be built (use -v for more details):
...
 - aeson-2.1.2.1 (lib) (requires build)

Then I can add constraints: and allow-newer: to the project. I think this has few advantages over cabal get:

• Since extra-packages are non-local, they get cached in the cabal store. So if I endup with a configuration I already visited nothing gets rebuilt.
• You can list multiple extra-packages: and you get a common build plan for both of them.
• cabal get is one of those commands that still don't read project configuration so I cannot use it with CHaP (half lying here, I think I could add the repository to the global configuration, but I don't think I want to do that).

With packages: . as default, you would get an error:

$ # Note the current directory is empty
$ echo -e "packages: .\nextra-packages: aeson" > cabal.project
$ cabal build --dry-run aeson
When using configuration(s) from /home/andrea/temp/cabal.project, the following errors occurred:
The package directory '.' does not contain any .cabal file.

Perhaps we can consider a better message to the user? Or maybe we could make use of optional-packages:?

$ # Note the current directory is empty
$ echo -e "optional-packages: .\nextra-packages: aeson" > cabal.project
$ cabal build --dry-run aeson
Build profile: -w ghc-9.2.8 -O1
In order, the following would be built (use -v for more details):
...
 - aeson-2.1.2.1 (lib) (requires build)

[ulysses4ever]

oh, that's smart: I only learned the cabal get way, but this looks far more advanced. I wonder how wide-spread this is. Anyways, we probably shouldn't blindly update the default without addressing the issue you raised. And I feel underqualified to suggest a solution. My guess that the practice is not widely used, and if there's a workaround via optional-packages, then there's more good then harm to change the default to . rather than empty.

[tupoiu]

Just encountered this today. I think adding the error message

Maybe you want to add the line packages: . to include your current directory as a package?

(or something similar) would be very helpful. It could just be added to the Warning with a newline and most people would be able to solve this themselves.