The PVP ought to mention dependency bounds (Was: Growing Haskell Platform)
Simon Marlow
marlowsd at gmail.com
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 gmail.com> 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-1.0.0.1 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-1.0.0.1?".
Cheers,
Simon
More information about the Libraries
mailing list