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

On 7 December 2012 16:30, Johan Tibell wrote:

On Fri, Dec 7, 2012 at 8:28 AM, Ian Lynagh wrote:

...

On Fri, Dec 07, 2012 at 08:20:41AM -0800, Johan Tibell wrote:

...

If B only bumps its patch-level version (i.e. to B-1.0.0.1), C no longer compiles (due to a version constraint failure) with B-1.0.0.1

Won't cabal-install select B-1.0 in that case, so installing C will still work?

See my aside at the end. Yes, it will backtrack and use the older version, but the users might get confused why the new version isn't used as it's version number suggests that it could be.

I agree with Ian here, we can find the solution ok and we don't need tighter constraints. Indeed it actually over-tightens, since if B can work with A-1.0 or 2.0 then we've eliminated a possible solution. Yes, the solver could and should tell us when it's not selecting the "best" (usually latest) version (it already does this) and why (it doesn't do that yet). Also, I don't think it scales, if we followed it strictly and said every major bump in any dependent package forces a bump on all things that depend on it, it'd just be far too much, especially when it's actually redundant. But yes it is true that the "real" API of a package is in the version number of the package itself, and the versions of all the packages which are "exposed" by that package (meaning packages that define types that are mentioned in the api of the exposing package). But it that has the property that I only notice changes in the types in those dependencies if I also depend on them directly myself. So we can get away with specifying local info, and not have to encode the full transative info (I think). Duncan