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

On 08/12/12 20:11, Duncan Coutts wrote:

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.

I agree with all that.

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).

This has always bugged me. I'd be surprised if your hypothesis here were true - it seems likely that if the types from a dependency leak into the API of a package, then the PVP applies to those "re-exposed" parts of the API too. One consequence of this is that if you have a non-private dependency and depend on a range of major versions, you better not re-expose any of the APIs that change between major versions. Otherwise your package has a random API, and that's not allowed. I didn't say anything in the PVP about this because I wasn't sure exactly what to say, but it would be good to nail it down. Cheers, Simon