increase error message detail for module lookups failure due to hi references

[duncan]

Consider the following build log. In particular note that we start by cleaning any local build files (rm dist).

Additionally, the user reports that transformers is not installed and ghc-pkg check reports no problems.

00:14:25 | morn@twi:~/dev/darcs/fastconvert -> rm -rf dist 
00:14:27 | morn@twi:~/dev/darcs/fastconvert -> cabal configure -v
[...]
Dependency attoparsec ==0.8.1.1: using attoparsec-0.8.1.1
Dependency base ==4.2.0.0: using base-4.2.0.0
Dependency bytestring ==0.9.1.5: using bytestring-0.9.1.5
Dependency cmdlib ==0.3: using cmdlib-0.3
Dependency containers ==0.3.0.0: using containers-0.3.0.0
Dependency darcs ==2.5: using darcs-2.5
Dependency datetime ==0.2: using datetime-0.2
Dependency directory ==1.0.1.0: using directory-1.0.1.0
Dependency filepath ==1.1.0.3: using filepath-1.1.0.3
Dependency hashed-storage ==0.5.4: using hashed-storage-0.5.4
Dependency mtl ==1.1.1.0: using mtl-1.1.1.0
Dependency old-time ==1.0.0.3: using old-time-1.0.0.3
Dependency utf8-string ==0.3.6: using utf8-string-0.3.6
Using Cabal-1.8.0.2 compiled by ghc-6.12
Using compiler: ghc-6.12.1
[...]
00:14:31 | morn@twi:~/dev/darcs/fastconvert -> cabal build -v          
[...]
/usr/bin/ghc --make -o dist/build/darcs-fastconvert/darcs-fastconvert -hide-all-packages -fbuilding-cabal-package -package-conf dist/package.conf.inplace -i -idist/build/darcs-fastconvert/darcs-fastconvert-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/darcs-fastconvert/darcs-fastconvert-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build/darcs-fastconvert/darcs-fastconvert-tmp -hidir dist/build/darcs-fastconvert/darcs-fastconvert-tmp -stubdir dist/build/darcs-fastconvert/darcs-fastconvert-tmp -package-id attoparsec-0.8.1.1-280af3ab9743111575ea0031e8a83455 -package-id base-4.2.0.0-73995e854f236dc2acd577d7c791221d -package-id bytestring-0.9.1.5-2d4a9d624c3be86b70c04730e5f12aca -package-id cmdlib-0.3-3ef785632945f8811c8ebbd1d2e9345b -package-id containers-0.3.0.0-409fe3b8f0dda25b98e03716d26be411 -package-id darcs-2.5-47653bbe1982b022915b3fa65161767f -package-id datetime-0.2-6f38d66fddaaa0ccccffea38d6fe8d60 -package-id directory-1.0.1.0-10fc46e61b67ff4a83f3e553454d003c -package-id filepath-1.1.0.3-07812de93a673f50011d47451bcaac87 -package-id hashed-storage-0.5.4-8a6b02d90d8e1d05f233c1e31eb4a367 -package-id mtl-1.1.1.0-7772b7b72936d947193a773ada65461a -package-id old-time-1.0.0.3-b53830b41b1085071f61ca7772f44e0c -package-id utf8-string-0.3.6-a7e240d06fa0c09cfff1a5445b521d24 -O -Wall -fno-warn-unused-do-bind ./main.hs
[1 of 5] Compiling Utils            ( Utils.hs, dist/build/darcs-fastconvert/darcs-fastconvert-tmp/Utils.o )
[...]
[3 of 5] Compiling Import           ( Import.hs, dist/build/darcs-fastconvert/darcs-fastconvert-tmp/Import.o )
Failed to load interface for `Control.Monad.Trans.Error':
  no package matching `transformers-0.2.2.0' was found

The message

Failed to load interface for `Control.Monad.Trans.Error':
  no package matching `transformers-0.2.2.0' was found

appears to be due to a .hi file from one of the dependencies of the current compilation. This hi file references a module from the transformers package.

1. it is hard for a user to know what is causing this module to be looked up (ie that it is a .hi file)
2. it is almost impossible to work out which existing registered package contains a .hi file that refers to the non-existent transformers package.

If the error message specified that it was a .hi file that caused the lookup and gave e.g. the file name (or package+ver+module) of the .hi file that caused the lookup of transformers then this would make it much easier for the user to work out what is going on and which registered package is at fault: e.g.

Failed to load interface for `Control.Monad.Trans.Error':
  the package `transformers-0.2.2.0' was found
  referenced by `Data.Foo` from `foo-1.0`.

Clearly there is a deeper problem here, that a registered package is out-of-sync with its registration information: the .hi refers to a package that is not mentioned in the package registration.

One way this could happen is due to inplace registrations, since it is easy in that case to rebuild the inplace .hi files without also re-registering. It may be sensible to rethink how Cabal does inplace registrations to prevent it getting out of sync.

We may also wish to have a ghc-pkg register/update/check mode that reads the .hi files and verifies them against the package registration info.

[duncan]

Replying to duncan:

Clearly there is a deeper problem here, that a registered package is out-of-sync with its registration information: the .hi refers to a package that is not mentioned in the package registration. One way this could happen is due to inplace registrations, since it is easy in that case to rebuild the inplace .hi files without also re-registering. It may be sensible to rethink how Cabal does inplace registrations to prevent it getting out of sync.

The user reports that one other possibility is that a dependency was cabal copyied but not re-registered.

The suggestion is that cabal copy could refuse to overwrite existing .hi files. So copy can be used to copy into a fresh temp dir, and subsequently registered, but not used to overwrite an existing installed package. For that the copy + register need to be done together.

Filed as  http://hackage.haskell.org/trac/hackage/ticket/802