cabal should handle missing build-depends better

[duncan]

It is a common complaint that missing build-depends causes unfriendly error messages.

For example  http://trevion.blogspot.com/2008/11/cabal-is-fine-piece-of-software.html writes

I noticed another nice Cabal feature upon first adding the line

import qualified Data.Map as Map

to my program. Of course, recompiling produced the message:

Preprocessing executables for interpreter-0.1...
Building interpreter-0.1...

src/Core.hs:8:17:
   Could not find module `Data.Map':
     it is a member of package containers-0.1.0.2, which is hidden

The commentator notes:

But really, my favorite feature is highlighted by the GHC
error message about not being able to find Data.Map. Of
course, Data.Map is on my system – GHC’s even found it, and
told me where it is. But Cabal’s made an important
distinction: just because I have software installed in my
development environment doesn’t mean I want to use it! Rather,
Cabal’s started out by hiding all the Haskell libraries
installed on my system. This helps me really appreciate the
packaging system, as I get to individually add each package
I’ve previously installed and then wish to use to my metadata
file. Of course, keep in mind, this is a per-project effort!
Even if I’ve used a library in one project, I might not want
to use it in my other projects.

Which is of course right. It is rather annoying.

For Cabal-2 we plan to track module dependencies directly rather than relying on ghc --make. In that case we have two options to improve the above situation. For quick and casual builds (perhaps not even using a .cabal file) we can just use the available packages and not complain. For packages that we expect to distribute we can either give warnings or errors about missing build-depends. In either case we can say exactly what is missing (not just the first) and we can make a reasonable suggestion about what version constraints to use.

[elga]

*  virgin mobile