QuickCheck versions and 'cabal install'

[Duncan Coutts]

On Thu, 2009-06-11 at 00:36 +1200, Stephen Blackheath [to cabal-devel]
wrote:
> All,
> 
> I'm getting a lot of this kind of problem now that a new major version
> of QuickCheck has come out...
> 
> blackh at amentet:~/src/projectx$ cabal install
> Resolving dependencies...
> cabal: dependencies conflict: Crypto-4.2.0.1 requires QuickCheck ==1.2.0.0
> however
> QuickCheck-1.2.0.0 was excluded because QuickCheck-2.1.0.1 was selected
> instead
> QuickCheck-1.2.0.0 was excluded because test-framework-quickcheck2-0.2.2
> requires QuickCheck >=2.1.0.0
> QuickCheck-1.2.0.0 was excluded because ProjectX-0.1 requires QuickCheck
> >=2.1
> 
> It isn't practical to fix this properly - That would require lots of
> work upgrading quickcheck on all dependent packages.  (Crypto-4.2.0.1 is
> my hacked version of Crypto-4.2.0 with a closed upper version limit to
> prevent it forcing QuickCheck-2.* which won't compile.)
> 
> Is there a better solution to this problem?

I think the Haskell Platform should help with this. The next major
release will almost certainly specify version 2.x.

Another solution is to allow private build dependencies. If the package
uses QC but does not export any QC types or QC class instances then its
use of it is effectively private and it would definitely be safe to
allow that private version to be different from some other version of QC
used elsewhere in the package dep graph.

Currently Cabal/cabal-install does not have enough information to know
which dependencies are private. It'd probably require a separate
build-depends field, and of course it'd then have to be properly
enforced.

> Should a package maintainer have the right to choose an old version of
> QuickCheck, or should cabal's policy force all package maintainers to
> upgrade (preferably all on the same day)?

I don't think Cabal itself can or should do anything about it. Trying to
coordinate people is more the purview of the platform.

Duncan