cabal cannot find cabal.project or *.cabal unless packages is defined

[ericnething]

I am using cabal 2.4.1.0.

In the cabal user guide section for cabal.project files, it states that the default value of packages: is ./*.cabal [Reference]. However, if you do not specify this explicitly in the file, cabal fails to find any cabal.project files or *.cabal files at all.

$ cabal new-build
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.

But as soon as I add the line packages: ./*.cabal, it works. Either the documentation is wrong, or the implementation is wrong, but I don't know which.

[hvr]

It's a documentation deficiency; the defaults for packages: and optional-packages: are implicit defaults which are only in effect if there is no explicit cabal.project file. Once such a cabal.project file exists, packages: and optional-packages: have an empty default (and this a good thing). Iow, the current behaviour was intentionally designed to be that way but the documentation fails to make this obvious.

We might also want to improve cabal's error message to detect when there's a cabal.project configuration which doesn't list any packages and give better hints.

[goldfirere]

I just hit this, being surprised that I need to write a packages: *.cabal line when that is documented as the default.

[jneira]

Issue about a better error message: #7401

[ulysses4ever]

Did it close the wrong issue? #8300 fixed the docs, so probably #7401 should have been closed instead. This one may be closed too, but it can also be turned into a feature request to extend the default to the situation when you have cabal.project, if people think it’s a desirable goal.

[ulysses4ever]

By the way, the default is set here and it seems fairly easy to apply it even if cabal.project is present:

cabal/cabal-install/src/Distribution/Client/ProjectConfig.hs

Lines 507 to 524 in 207d4ee

	readProjectConfig :: Verbosity
	-> HttpTransport
	-> Flag Bool -- ^ @--ignore-project@
	-> Flag FilePath
	-> DistDirLayout
	-> Rebuild ProjectConfigSkeleton
	readProjectConfig verbosity httpTransport ignoreProjectFlag configFileFlag distDirLayout = do
	global <- singletonProjectConfigSkeleton <$> readGlobalConfig verbosity configFileFlag
	local <- readProjectLocalConfigOrDefault verbosity httpTransport distDirLayout
	freeze <- readProjectLocalFreezeConfig verbosity httpTransport distDirLayout
	extra <- readProjectLocalExtraConfig verbosity httpTransport distDirLayout
	if ignoreProjectFlag == Flag True then return (global <> (singletonProjectConfigSkeleton defaultProject))
	else return (global <> local <> freeze <> extra)
	where
	defaultProject :: ProjectConfig
	defaultProject = mempty {
	projectPackages = ["./"]
	}

[Mikolaj]

Yes, I think the ticket number was mixed up in the PR description and github just followed that. Let me re-open.

[jneira]

Hmmm so finally this should be closed by #8300 (and no #7401 which has been reopened) , right?

[ulysses4ever]

@jneira my view is that this ticket can be turned into a feature request to extend the default on cabal.project. But if people disagree, I could open a separate ticket. Or if people think it's a bad idea (for the default), we can just close this one and forget about it, yes.

[jneira]

hmm i would open a specific issue about the feature, to make it more visible and hopefully provoke a discussion about, but as you consider, of course

[ulysses4ever]

All right, let's close then.

[ulysses4ever]

If @Mikolaj agrees that is.

[Mikolaj]

Sounds like a plan, though I'd close after the other ticket is opened and mentioned here so that we don't forget.

[navid-zamani]

have an empty default (and this a good thing).

I just ran in circles, trying to find, why “it’s a good thing”. I can see no benefit over a sensible default. And neither could anyone else I came across. So since I’m assuming your statement is based on something you remember, I’m curious: Could you share that good reason with us, so one can at least find it? (Or, alternatively, correct the statement, of course. ;)

[Mikolaj]

For the record, this statement came from @hvr, who is not active in cabal development any more.

If I were to guess, empty default for packages may be good, because it prevents clashes with packages specified by other means. However, since @hvr said it 3 years ago, we have fixed the problem of duplicates in packages in multiple cabal.project.* files causing a crash (or we only plan to fix it? I don't remember. There must at least be a ticket.). So perhaps this default is no longer required.

That's only my guess. Perhaps others have better guesses.