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

[Gregory Collins]

On Mon, Feb 24, 2014 at 10:44 PM, Michael Snoyman <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.


That's because you maintain a lot of packages, and you're considering
buildability on short time frames (i.e. you mostly care about "does all the
latest stuff build right now?"). The consequences of violating the PVP are
that as a piece of code ages, the probability that it still builds goes to
*zero*, even if you go and dig out the old GHC version that you were using
at the time. I find this really unacceptable, and believe that people who
are choosing not to be compliant with the policy are BREAKING HACKAGE and
making life harder for everyone by trading convenience now for guaranteed
pain later. In fact, in my opinion the server ought to be machine-checking
PVP compliance and refusing to accept packages that don't obey the policy.

Like Ed said, this is pretty cut and dried: we have a policy, you're
choosing not to follow it, you're not in compliance, you're breaking stuff.
We can have a discussion about changing the policy (and this has definitely
been discussed to death before), but I don't think your side has the
required consensus/votes needed to change the policy. As such, I really
wish that you would reconsider your stance here.

I've long maintained that the solution to this issue should be tooling. The
dependency graph that you stipulate in your cabal file should be a
*warrant* that "this package is known to be compatible with these versions
of these packages". If a new major version of package "foo" comes out, a
bumper tool should be able to try relaxing the dependency and seeing if
your package still builds, bumping your version number accordingly based on
the PVP rules. Someone released a tool to attempt to do this a couple of
days ago --- I haven't tried it yet but surely with a bit of group effort
we can improve these tools so that they really fast and easy to use.

Of course, people who want to follow PVP are also going to need tooling to
make sure their programs still build in the future because so many people
have broken the policy in the past -- that's where proposed kludges like
"cabal freeze" are going to come in.

G
-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140225/f9816ab4/attachment.html>