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

[Michael Snoyman]

On Wed, Feb 26, 2014 at 9:45 PM, Yitzchak Gale <gale at sefer.org> wrote:

> 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.
>
>
Actually, that's not going to help anyone much. If the library really is
completely stable, then who cares if I have to change an upper bound when
the package never changes?

The real issue is packages with a largely stable subset, and some other
part that's still changing. The two prime examples of this are text and
bytestring. Both of them expose an incredibly stable core API, which is
what most people use. Occasionally, there is a new feature added, or some
more obscure feature changes somehow. But likely 95% of packages depending
on these two will never be affected by those changes.

Requiring every usage of text to have an upper bound stratifies Hackage
into (1) packages that depend on the new features, and (2) PVP-adhering
packages whose authors haven't updated their dependencies yet.

With my Stackage hat on, this is by far the most time-consuming issue I
have to deal with. base squarely falls in this category, since the vast
majority of it doesn't change between releases. It happens to *also* fall
in the category of non-upgradeable packages.


> 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.
>
>
To be clear, base has a major version bump every release of GHC. According
to the PVP, the first two components of the version number constitute the
major version, while the third number is the minor version.


> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140226/c7b9af68/attachment.html>