QuickCheck versions and 'cabal install'

[Stephen Blackheath [to cabal-devel]]

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