requiring consistent package dependencies can give surprising results

[bos]

(Imported from Trac #511, reported by guest on 2009-02-27)

I tried running this command:

sudo cabal install test-framework test-framework-hunit test-framework-quickcheck test-framework-quickcheck2

However, Cabal barfed with:

Resolving dependencies...
cabal: cannot configure test-framework-quickcheck-0.2.1. It requires
QuickCheck >=1.1 && <2
For the dependency on QuickCheck >=1.1 && <2 there are these packages:
QuickCheck-1.1.0.0 and QuickCheck-1.2.0.0. However none of them are available.
QuickCheck-1.1.0.0 was excluded because QuickCheck-2.1.0.1 was selected
instead
QuickCheck-1.1.0.0 was excluded because test-framework-quickcheck2-0.2.1
requires QuickCheck >=2.1.0.0
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.1
requires QuickCheck >=2.1.0.0

This seems to be because the quickcheck and quickcheck2 providers for test-framework by design depend on disjoint versions of `QuickCheck?`. This should not confuse cabal install, since installing the packages sequentially in any order works fine:

sudo cabal install test-framework test-framework-hunit test-framework-quickcheck
sudo cabal install test-framework-quickcheck2

[bos]

(Imported comment by @dcoutts on 2009-02-27)

What it is doing is guaranteeing that you will be able to use all of these packages together consistently. By installing separately it is only providing that guarantee locally for each set of packages you install together. This is by design.

If you now make a package that depends on both test-framework-quickcheck test-framework-quickcheck2 then the solver will still complain.

Sadly there is not enough information available to do a better job. If we knew that there was guaranteed to be no clashes due to diamond dependency errors then the solver could be more relaxed. We could also imagine allowing the solver to find only local consistency for each top level target you specify. That's not what people generally want by default however. We could allow local only local consistency with a flag, but it's work to do and it's achievable, as you noticed, by invoking install several times. If this turns out to be something people want to do frequently then we should perhaps revisit it.

This example is interesting because it looks like it is explicitly setting up exactly the situation the solver is designed to avoid. That is, having a situation where one package depends on test-framework-quickcheck and test-framework-quickcheck2 and mistakenly unifies types re-exported from quickcheck-1.x and quickcheck-2.x. In this example it's part of the design that they are separate types that the user should not expect to unify where as normally with these things the user would expect to unify them. If we wanted this example to work better then somehow we need more information to know that this is how it's supposed to work and that it's not a mistake.

Changing the summary to reflect the cause.

[bos]

(Imported comment by @kosmikus on 2009-02-27)

I'm planning to have a flag for the modular solver that allows this to work. I'm not sure if it'll be working fine in the upcoming release, but it should be working eventually, once private dependencies are finally sorted out, too.

[bos]

(Imported comment by @kosmikus on 2012-03-06)

Not working properly yet, delaying to the next release.