[Hackage] #511: requiring consistenct package dependencies can give surprising results

[Hackage]

#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