#511: requiring consistenct package dependencies can give surprising results ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: low | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: unknown Ghcversion: | Platform: ---------------------------------+------------------------------------------ Changes (by duncan): * summary: cabal-install too eager about resolving dependencies => requiring consistenct package dependencies can give surprising results Comment: 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. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/511#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects