On Tue, Dec 11, 2012 at 8:34 AM, Simon Marlow
On 11/12/12 16:14, Johan Tibell wrote:
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).
It's still a local statement: if we changed the PVP (which I don't suggest we do at this point), it would be to require that every time you bump a lower version bound on a dependency you have to bump your own major version number. You don't have to recursively look at all your dependencies as we assume they also follow the PVP.
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?".
Better diagnostic is probably they way forward for now. I feel that cabal used to be better at telling me why it made certain dependency choices. Now it tells me very little (i.e. basically a list of packages it tried, without information about why they were tried). -- Johan