The PVP ought to mention dependency bounds (Was: Growing Haskell Platform)

Simon Marlow marlowsd at
Tue Dec 11 17:34:05 CET 2012

On 11/12/12 16:14, Johan Tibell wrote:
> On Tue, Dec 11, 2012 at 1:45 AM, Simon Marlow <marlowsd at> wrote:
>> I'm a bit lost.  The example from your mail that started this thread *does*
>> compile, because Cabal finds a valid install plan by avoiding the new
>> version of B. It's working exactly as intended, isn't it?  Then you said
>> that the user might get confused about why the new B wasn't being used, to
>> which the response is that we need better diagnostics.
>> What's the problem you're getting at above?
> The problem is one of two things, depending on how you look at it. On
> the one hand, if we take "C-1.0 depends on A-1.0.0.*" to mean that C
> states that it can work with any version of A-1.0.0, that is a lie (as
> per the scenario in my original email) and the PVP needs to be
> adjusted.

If users expect this interpretation, then I think we should tackle that 
with better documentation. It's important that the dependencies on a 
package are a *local* statement about the APIs that *this* package 
requires, and don't need to take into account constraints imposed elsewhere.

The consequences of the alternative are pretty severe: every package 
author basically has to do Cabal's job and perform a backtracking 
search, solving the constraints so they can put the results in their 
build-depends.  Furthermore they would have to re-do this every time a 
new constraint is added to the system (somebody uploads a new package 
that might be a dependency of one of yours).

> On the other hand, if you take "C-1.0 depends on A-1.0.0.*" to mean
> that C states that it can work with the A-1.0.0 API then users and
> developers might get confused when newer releases of libraries don't
> get picked up even though the version bounds suggests that they would.
> We could try to solve this by cabal telling the user about when this
> situation appears, but understanding why package version conflicts
> appear is already hard to understand for users.

Right, better diagnostics is the solution.

   I couldn't use B- because it depends on A-2.0
     and I couldn't use A-2.0 because C requires A-1.0.0.*

Although, listing all the solutions that *don't* work will quickly get 
very verbose.  This is a tricky UI problem.  Perhaps there should be a 
way to ask questions - "why didn't you use B-".


More information about the Libraries mailing list