Duncan, Thank you for the reply. I really like the private dependencies solution, i.e. a 'build-depends-private' field for depending on something (e.g. QuickCheck) that doesn't form part of the external API. I think it would work very well. Enforcing it by checking that the library doesn't export any APIs containing types from private dependencies would be wonderful. Conversely we could also make suggestions to the user where a library uses something privately only but it isn't marked as private. But I can't see any easy way to implement it in Hackage or in 'sdist' where it's really needed (since it requires doing a build). I'll keep this in the back of my mind. Steve Duncan Coutts wrote:

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...

...

=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

blackh@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 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