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