
On 11/12/12 16:14, Johan Tibell wrote:
On Tue, Dec 11, 2012 at 1:45 AM, Simon Marlow
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