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

[Vincent Hanquez]

On 2014-02-25 15:12, Brandon Allbery wrote:
> On Tue, Feb 25, 2014 at 1:44 AM, Michael Snoyman <michael at snoyman.com 
> <mailto:michael at snoyman.com>> wrote:
>
>     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.
>
>
> I have a question for you.
>
> Is it better to save a developer some work, or is it better to force 
> that work onto end users?
>
As a *user* of many libraries, I had more problems with libraries that 
follow the PvP religiously than the other way around. I usually like to 
have the latest and greatest libraries, specially text, aeson, and such, 
and there I have to manually bump dependencies of packages I depend on, 
until the developers gets to update the package on hackage (which 
sometimes takes many weeks).

As a *developer*, following the PvP would cost me a lot of my *free* 
time. This is particularly true when the surface of contact with a 
library is small, it's very unlikely that I will run into an API 
changes. When I do, I release a new package quickly that account for the 
API change, or I can put a upper bounds if I can't make the necessary 
changes quickly enough. I usually found out quite quickly with stackage 
nowadays, most of times, before any users get bitten.

Some other time, I'm testing some development ghc or some new unreleased 
libraries, and I need to remove upper bounds from packages so that I can 
test something.

Anyway, there's lots of reason that the PvP doesn't works fully. It 
solves some problems for sure, but sadly swipe all the other problems 
under the carpet. One problem being that a single set of numbers doesn't 
properly account for API complexity and stability that might differ in 
different modules of the same package.

-- 
Vincent