
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

I think using the runTests hook and the test flag make sense,
described at http://www.haskell.org/pipermail/haskell-cafe/2008-September/047223.html.
I released some libraries in this way, AFAIK it works well.
On Sun, Sep 6, 2009 at 4:57 PM, Christopher Lane
Hinson
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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (2)
-
Christopher Lane Hinson
-
Yusaku Hashimoto