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

[Duncan Coutts]

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.

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