search

haskell / hackage-security

Hackage security framework based on TUF (The Update Framework)
http://hackage.haskell.org/package/hackage-security
56 stars 47 forks source link

testsuite bounds needlessly restrictive #214

Closed clinty closed 11 months ago

hvr commented 6 years ago

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.

clinty commented 6 years ago

Nevertheless these bounds are needlessly restrictive and cause us additional work.

hvr commented 6 years ago

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"?

clinty commented 6 years ago

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.

Mikolaj commented 2 years ago

Hi @clinty, if you'd like to suggest the relaxed bounds, I think I can sneak them in before the forthcoming release.

andreasabel commented 11 months ago

Issue looks stale...