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

[Simon Marlow]

On 08/12/12 20:11, Duncan Coutts wrote:
> On 7 December 2012 16:30, Johan Tibell <johan.tibell at gmail.com> wrote:
>> On Fri, Dec 7, 2012 at 8:28 AM, Ian Lynagh <ian at well-typed.com> 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