new-{build,repl} incorrectly looks at any directory that exists for dependencies

[TomMD]

As demonstrated by @aisamanra's minimum example.

If you have a cabal project with the cabal.project.local of:

packages: ., deps/foo

And there exists a spurious ./foo copy of the package in addition to the deps/foo then new-build will try to use the top level directory instead of (in addition to? unsure) the pointed-to directory nested indeps.

[hvr]

@TomMD does your cabal.project file specify any packages: as well?

[TomMD]

@hvr There is no cabal.project file.

I've patched the example to be a bit more in-your-face with the issue but at a new repo location. Observe:

$ git clone https://github.com/TomMD/broken-cabal-test.git
...
$ cd new-build-project-bug
$ cat cabal.project.local
packages: ., dep/foo
$ cat dep/foo/foo.cabal | grep ^version
version:          0.2.0.0
$ cat foo/foo.cabal | grep ^version
version:          0.1.0.0
$ cat sample.cabal| grep foo
  build-depends:       base, foo >= 0.2.0.0

So we should build dep/foo since that is what the project points towards. Only the copy of foo in dep has the right version (>=0.2.0.0) while the excess copy of foo is version 0.1.0.0.

$ cabal new-build sample
Resolving dependencies...
cabal: Could not resolve dependencies:
next goal: foo (user goal)
rejecting: foo-1.0, foo-0.2.0.0 (constraint from user target requires
==0.1.0.0)
rejecting: foo-0.1.0.0 (constraint from user target requires ==0.2.0.0)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: foo

[hvr]

There is no cabal.project file.

Well, that's the problem then :-)

Explanation: if there is no cabal.project, you get the implicit default (which I just realised is wrongly documented) for packages, i.e.

packages: ./*.cabal
optional-packages: ./*/*.cabal

which is combined with the one from your .local file, resulting in

packages: ./*.cabal, deps/foo
optional-packages: ./*/*.cabal

which explains what you're seeing.

What's not properly documented is when these defaults are relevant: these defaults only matter when you don't have any cabal.project (i.e. not a .local!) file. As soon as you have a cabal.project file, the defaults are changed to empty packages: and optional-packages:.

[TomMD]

I'd argue this is a mis-feature which should be removed. It is bound to cause lots of confusion and I don't know of anyone using new-build in a manner that implicitly includes the immediate subdirectories.

An unhappy alternative is to add an additional feature of either:

• fail with a sensible message when two packages have the same name
• Detect when an implicit package has the same name as an explicit one and ignore the implicit.

[hvr]

@TomMD I symphatise with your complaint, as I've been confused myself when I started using early new-build prototypes. By now I guess I've become used to it.

The original rationale for doing it this way (iirc -- I could be wrong; it was @dcoutts who invented the optional-packages-default) was to support the following workflow w/o having to create any cabal.project file, while having cabal new-configure not break things:

$ git clone someproj
$ cd someproj
$ cabal unpack some-dep-a some-dep-b
...fixup/modify some-dep-a and some-dep-b
$ cabal new-configure -w ghc-7.10.3
$ cabal new-build

"Detect when an implicit package has the same name as an explicit one and ignore the implicit."

tbh, I think that one's really unhappy, as it'd be imho rather non-obvious/too magically. I'd rather sympathise with having optional-packages default to an empty value (but keeping the packages: . default when there is no cabal.project file, as that's imho obvious/non-controversial).

[phadej]

optional-packages are set to empty by default in. #6740