Overly tight bounds on `QuickCheck`, `tasty`, and `tasty-quickcheck`
taktoa opened this issue · comments
It builds fine with:
QuickCheck == 2.11.3tasty == 1.1.0.3tasty-quickcheck == 0.10
but the current bounds in the Cabal file break the build in this case.
Hi,
The bounds probably are tighter than necessary, but does this cause an issue in practice? I thought the test dependencies only need to be installed if you're building limp on its own, in which case you can use a sandbox.
I'm a bit busy for the next two months, but I'll get a chance to look at this properly after October.
I thought the test dependencies only need to be installed if you're building limp on its own
There are systems where tests are built and ran as part of installing dependencies. nix package manager by default does this for example, if using the Haskell packages from nixpkgs repository. It's a good sanity check anyway.
I came here to confirm that 12c3af2 fixes the issue reported here: previously I ended up disabling the tests for this package.
Fair enough. It makes sense to build the tests anyway, but it seems a bit restrictive to require the test dependencies of all dependent packages to have the same version. I guess it must save a lot of rebuilding though.
Do you use the version on hackage? Would it be useful for me to update that? Also, do you use the limp-cbc bindings to the COIN solver? The results can be flakey sometimes and it's slower than the external binary, so I was thinking about replacing limp-cbc to shell out.
but it seems a bit restrictive to require the test dependencies of all dependent packages to have the same version
It works better than one could expect. Think about Stackage which only has a single version of every package and it does run tests for all the packages.
Do you use the version on hackage? Would it be useful for me to update that?
Personally I'm currently pointing at this repository directly. It'd be useful for it to be on Hackage so that other people can easily benefit. Further, if it's on Hackage then it will make its way to nixpkgs and I can stop having to manually override this package to use the git repository and can benefit from the upstream. So, yes please!
Also, do you use the limp-cbc bindings to the COIN solver? The results can be flakey sometimes and it's slower than the external binary, so I was thinking about replacing limp-cbc to shell out.
Personally I do not use these so I can't comment.
Cool, I'll upload a new version to hackage soon.
I've released version 0.3.2.3 on hackage, so I'm going to close this. Let me know if you have any issues.
I meant to also say: I changed the pretty-printer slightly in this release to add an "End" line at the end. Cbc needed that to parse the programs, but I think GLPK accepted it without. Hopefully most solvers accept both with and without.