There are some libraries that depend on QuickCheck 2, and others that depend on QuickCheck 1. This can be a problem. AIUI, the Haskell Platform current depends on QC1, but intends to move to QC2 soon. I also know that the cabal mailing list has talked about some kind of private-depends capability to mitigate this kind of thing in the future. However, I don't see how it can possibly be a best practice to depend on QuickCheck from a shipping library. End users never use this, and for users of upstream packages who may compile from source and contribute the occasional (but valuable!) patch, this is nothing but a compile-time problem waiting to happen. (Note that a user who contributes to a library should be encouraged to run test suites, but I'm talking about users of upstream packages.) There are some good ideas discussed on this list last year*, but none of them seem to have been blessed by the community. * http://www.haskell.org/pipermail/haskell-cafe/2008-September/047216.html Friendly, --Lane