hackage-security
hackage-security copied to clipboard
haskell
testsuite bounds needlessly restrictive
test-suites don't participate in the install-plan solving when hackage-security is used as a library; hence we don't need to keep them working w/ the latest dependencies at all times.
Nevertheless these bounds are needlessly restrictive and cause us additional work.
In order to better understand your concern and make sure there isn't some misunderstanding on the mechanics of cabal dependency specifications, I'd like to ask you a couple questions: What evidence do you have to support the claim of being "needlessly restrictive"? Who is "us"? And what exactly do you mean by "additional work"?
Sorry. "us" in this context is Debian.
For the specific hackage-security example, we need to patch the .cabal file because we have tasty-quickcheck 0.9.2. At present we need to do this in the package plan, and we need to do it a second time in the hackage-security source package itself. Since the tests build perfectly fine with tasty-quickcheck 0.9.2, I am calling the lower bound needlessly high.
In contrast, we also need to patch the cabal file for QuickCheck 2.10.1, but this also requires code changes to the test to cope with the changed Arbitrary instance for Char. So the upper bound is appropriately restrictive, even though we still have to patch it.
I hope that clarifies.
Hi @clinty, if you'd like to suggest the relaxed bounds, I think I can sneak them in before the forthcoming release.
