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

[Yitzchak Gale]

Michael Snoyman wrote:
> 1. Make sure that any code that anyone ever wrote will continue to build in
> the future.
> 2. Provide guidelines to package authors to make sure that `cabal install
> foo` works reliably, regardless of what's happened on the rest of Hackage.
>
> It's (1) that I take huge issue with, because (as I've been trying to
> demonstrate) I don't see any way that a policy like PVP could ever fully
> solve this problem.

As a commercial shop that must reproduce builds,
we have wasted many many hours in the past on
cabal hell. Almost all of it was caused by authors
of packages we depend on omitting upper bounds.

I am aware that some people have other needs,
and have wasted their cabal hell time on the opposite
problem.

However, now the amount of time we waste on cabal
hell, though non-zero, is much less. The reason is better
ways in cabal to tweak cabal's build plan manually and
reproduce winning build plans in the future, such as
local cabal.config files. Whatever time we still do waste
is still caused by people not being careless about
upper bounds. And I believe that people with the
opposite problem are wasting less and less time
on cabal hell, too.

As better tools continually become available, it
becomes less disastrous when dependency
version bounds are not exactly right. But on the
other hand, those bounds are critically important
semantic information about a package that make
a huge contribution to the potential quality that
build tools can achieve. And only the package author
can easily provide that information

So in my opinion, the proven, working, way forward is:

1. Continue to improve cabal's build plan tools, such
as cabal freeze. And yes, cabal-timemachine would
be cool :)

2. Continue to adhere to PVP. Package authors should
do the best they can to guess the range of dependency
versions that their package is very likely to build with.

So for example:

For libraries like the tagged library, or the deepseq library,
which haven't changed in any essential way over any number
of major version bumps, go ahead and omit the upper
bound.

For most vanilla packages, try to be as accurate as you
can about the lower bound (without going crazy), and
use a two-component upper bound.

For base, if you are not using fancy new GHC features,
minor version bumps are unlikely to break your package,
but a major bump of base (if that will ever happen again)
is likely to break quite a few packages and maybe yours.

For maintainers like Edward with a huge burden - well,
I'm sure Edward will figure out the most reasonable
and helpful thing to do in his situation. Perhaps higher
powered tools, like some variation on cabal-bounds,
would be helpful for him.

Etc.

Thanks,
Yitz