search

amosr / limp

ideally, this will become a pure Haskell library for Linear Integer/Mixed Programming
MIT License
16 stars 5 forks source link

Overly tight bounds on `QuickCheck`, `tasty`, and `tasty-quickcheck` #3

Closed taktoa closed 5 years ago

taktoa commented 6 years ago

It builds fine with:

but the current bounds in the Cabal file break the build in this case.

amosr commented 6 years ago

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.

Fuuzetsu commented 5 years ago

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 12c3af23d16b889aa2d854c148a90bbd16fce35f fixes the issue reported here: previously I ended up disabling the tests for this package.

amosr commented 5 years ago

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.

Fuuzetsu commented 5 years ago

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.

amosr commented 5 years ago

Cool, I'll upload a new version to hackage soon.

amosr commented 5 years ago

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.

amosr commented 5 years ago

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.