On Wed, Feb 26, 2014 at 9:45 PM, 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.
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