qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method)

[Ganesh Sittampalam]

On 25/02/2014 06:44, Michael Snoyman wrote:

> Next is the issue of PVP. I am someone who has stopped religiously
> following the PVP in the past few years. Your email seems to imply that
> only those following the PVP care about making sure that "packages work
> together." I disagree here; I don't use the PVP specifically because I
> care about package interoperability.
> 
> The point of the PVP is to ensure that code builds. It's a purely
> compile-time concept. The PVP solves the problem of an update to a
> dependency causing a downstream package to break. And assuming everyone
> adheres to it[1], it ensures that cabal will never try to perform a
> build which isn't guaranteed to work.
> 
> But that's only one half of the "package interoperability" issue. I face
> this first hand on a daily basis with my Stackage maintenance. I spend
> far more time reporting issues of restrictive upper bounds than I do
> with broken builds from upstream changes. So I look at this as purely a
> game of statistics: are you more likely to have code break because
> version 1.2 of text changes the type of the map function and you didn't
> have an upper bound, or because two dependencies of yours have
> *conflicting* versions bounds on a package like aeson[2]? In my
> experience, the latter occurs far more often than the former.

It's worth mentioning that cabal failing to find a solution is far less
costly for me to discover than cabal finding a solution and then having
a build of a large graph of packages fail, because by that point I've
wasted a lot of time waiting for the build and I now have a thoroughly
confused package database to recover from (whether using a sandbox or not).

Ganesh