Michael Snoyman wrote:
I still have some concerns about the PVP's stance on a few issues, namely:
1. The upper bounds on non-upgradable packages, which I've raised elsewhere in this thread. 2. The lack of flexibility in interpretation. I think there's a qualitative difference between depending on the text package by simply importing Data.Text (Text), versus using some experimental features of a version 0.1 library.
So I suppose if those points were addressed, a lot of my PVP skepticism would disappear, and I'd be more inclined to coming back into the fold, so to say.
My question is: am I alone in thinking these are in fact issues with the PVP?
Roman Cheplyaka wrote:
No, you're not alone. And here are two other issues with PVP and upper bounds: http://ro-che.info/articles/2013-10-05-why-pvp-doesnt-work.html
I appreciate those concerns, but they are all concerns about being able to build packages, not about the semantics of the PVP. Trouble with building is being addressed by improvements in cabal, combining better algorithms with better quick and easy ways to intervene manually. I now find that even when thing go very wrong - complex dependency SATs, errors in package versions or dependency bounds in other people's packages, etc. - I can usually get a successful build quite quickly, and I hope this will only continue to improve. I agree 100% with Michael's #2 - dependency bounds ranges are a way of expressing the package author's best assessment of what is needed, and what will likely be needed in the foreseeable future, for the package to build. They don't need to follow any hard and fast rules. But yes, an upper bound is called for in most cases. Roman is right that it is important for package authors to do the best they can to support the latest versions of their dependencies. But even when they do that, upper bounds are not useless. They are important for people using your packages who need to support a product version over time. And they are important semantic information that you can easily make available for use by current and future build tools. Thanks, Yitz