Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Refactor Http4sMatchers to be generic on F-Type #2080
As described in issue #1430, the
Other issues and related or future work.
One thing to note is that, in the
These methods have no type-class capturing them, although an issue was opened in
It should be noted that, since the existing design is a lattice of inheritance and mixins, the solution only adds two more nodes to that lattice. While it may be possible to replace the design by one with less inheritance, which would avoid the inner (path-dependent) class
specs2 has recently gained support for
RunTimedMatchers here extend specs2 but aren't HTTP-specific. I'm wondering if we should offer those traits to specs2-cats, and then restrict this just to the polymorphic
Getting from here to there is complicated: specs2 now depends on scalacheck-1.14, but our laws dependencies are only published for scalacheck-1.13. I think this strategy is the right place to put things in the long term, but severely complicates getting this merged and released.
I'd also like to have an http4s-laws (no specs2 dependency) and an http4s-specs2 module for the matchers. Maybe that split could be coordinated with a scalacheck-1.14 upgrade and give us an excuse to adopt a specs2-owned trait, and we adopt these as a temporary fix.
I agree that
As for the
I think the problem with
@rossabaker I have opened a PR in
Looking through the build files of those projects, I have found a curious thing:
In any case, I humbly believe that upgrading test dependencies, and watching for any regression that may introduce, goes beyond the scope of the original issue.
We're going to have a mess when Scala 2.13 forces us to straddle the scalacheck-1.13 vs. 1.14 divide. Hopefully we can get cats-laws and cats-effect-laws crossbuilt for 1.14 by that point. But we'll cross that bridge when we come to it: this is strictly an improvement where we're at today.