[Hackage] #511: cabal-install too eager about resolving dependencies
#511: cabal-install too eager about resolving dependencies ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: low | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ 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 }}} -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/511 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#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
participants (1)
-
Hackage