Please relax constraint on conduit
peti opened this issue · comments
The library builds fine with the latest version of conduit after the restrictions are removed from the cabal file.
The slight difficulty is that conduit has been refactored so it would require some conditionalisation to also build with the older version - see #56 (comment)
I'd like to keep the test harness working on older GHCs if possible so I want to check whether bumping the lower bound is compatible with that.
I guess there's also a slightly more fundamental question here - this is just the test harness and so (a) the conduit version we use isn't at all important as the goal is to test HTTP, not conduit and (b) the conduit dependency doesn't actually need to infect any higher-level libraries that depend on HTTP. But I think if you do cabal install --enable-tests on something that depends on HTTP either directly or indirectly, then cabal will still want to find a consistent plan even though it's not strictly necessary.
I'm sorry, but I don't follow. Why exactly don't you want to lift that restriction on conduit?
@hsenag we could try to build the testsuite as part of the travis job, that way we'd ensure (or at least get notified) the testsuite keeps building with all the configured GHCs in the build-matrix.
However, I'd advise against omitting any upper bounds on conduit, to avoid having the travis build broken due to external changes in the conduit's API, rather than a change inside the HTTP package.
@peti - I can't raise the upper bound without also raising the lower bound, because the two different versions of conduit aren't compatible.
@hvr - yes, I definitely don't want to omit upper bounds.
@hsenag, okay ... I didn't notice any incompatibilities, but that's probably because I cannot build the test suite anyway.
Okay, now I see what you guys meant. The latest release fixes the test suite build -- and now that I can actually compile the test suite, I see the build failure that arises from the incompatibility with the latest version of conduit. Too bad. :-(
I will look to raise the upper and lower bounds when I get a chance to check on the impact (or conditionalise the build) - just needs a bit more time than I have free right now.
Why do we have this httpd test with huge dependencies on conduit, warp, httpd-shed etc? If the point is to test that the network library can support an httpd, we could just test something simple like https://gist.github.com/butaji/998111 . If the point is to test warp then the test belongs in another package.
It's to verify that the HTTP client works by running a local server to connect to. As I mentioned in #61 (comment) I think it's mainly an issue because it causes Cabal to constrain other things in the stack to the same versions of these dependencies when there's no direct need for that constraint. I guess there's also the question of distributions which would generally prefer to use one version of each library.
@hvr - I think @tibbe disabled the test suite for Travis because it upsets the cabal install dependency solver (see bbb2867). In general I'm not very keen on relying on Travis, in part because it doesn't cover Windows and typically that's not tested by patch submitters either.
@peti - I've bumped the dep with conditionalisation now.