Ticket #476 (new enhancement)
cabal should handle missing build-depends better
|Reported by:||duncan||Owned by:|
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.