Relax mtl requirement

[phadej]

This let tasty compile with bundled transformers-0.3 with GHC-7.8.*.
That's important for packages using e.g. doctest in their (other)
test-suites, as then transformers cannot be re-installed.

[RyanGlScott]

Thanks! This is the fix for #200 that I was too lazy to write myself :)

[phadej]

Don't merge yet, I'll amend this PR in a few minutes.

[phadej]

This also broke Cabal build:

I made second revision for tasty-1.0

EDIT interestingly 0.14 version is used with LTS-6 matrix job: https://travis-ci.org/feuerbach/tasty/jobs/326915284#L544 (from the first commit of this PR). Is it a bug in stack? Answer not it isn't as there is extra-deps: optparse-applicative-0.14.0.0 in stack.yaml.

[UnkindPartition]

Thanks Oleg, I'll merge & release shortly. Do you know why Cabal sometimes picks older versions of dependencies? Is there a way to catch these types of breakage before a release?

Edit: just realized this doesn't need a release.

[phadej]

Roman, there's some package with a bound forcing solver to pick older release. In the Cabal case above it's simple: http://hackage.haskell.org/package/hackage-repo-tool (dependency of test suite) has optparse-applicative <0.14 bound.

About testing the lower-bounds. You might noticed a recent blog post of mine which introduces trustee tool: http://oleg.fi/gists/posts/2018-01-08-haskell-package-qa.html#s:6, I used that to find out that optparse-applicative bound was too lax. (The Cabal issue was reported independently, also though). But when true bounds are found, you could assemble a stack-lower.yaml with extra-deps set to lowest possible versions, which make a valid install plan. E.g. for GHC-7.8.4 you could set:

ansi-terminal         0.6.2   
async                 2.0.1.5 
clock                 0.4.4.0 
mtl                   2.1.3.1 
optparse-applicative  0.14.0.0
stm                   2.3     
tagged                0.7
unbounded-delays      0.1.0.6 

It won't be perfect, as a version of dependency might work with some GHC and don't with other, but still - better than nothing.

[UnkindPartition]

Roman, there's some package with a bound forcing solver to pick older release.

That's what I thought, but then adding a lower bound wouldn't fix it, right? It would just lead to an absent build plan. At least in Ryan's case, when I bumped the mtl bound, his build worked, which means there wasn't a hard upper bound.

About testing the lower-bounds. You might noticed a recent blog post of mine which introduces trustee tool

Nice! (I saw it earlier, but didn't realize it was useful for me since I'm not a trustee.) So, could I just add trustee bounds --lower --verify to my travis.yml?

[UnkindPartition]

Oh wait, I do need to make a release to relax the mtl bound. Released as 1.0.0.1 now.

[phadej]

@feuerbach thanks for the release!

That's what I thought, but then adding a lower bound wouldn't fix it, right?

In Cabal case, yes, it cannot yet use tasty-1.0, the good thing is that cabal-install solver error mentions hackage-repo-tool, tasty and optparse-applicative: E.g. if I add a tasty dependency to currently latest hackage-repo-tool-0.1.1:

hackage-repo-tool-0.1.1 % cabal new-build --enable-tests --constraint='tasty >=1.0' hackage-repo-tool
...
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: optparse-applicative, tasty,
hackage-repo-tool

hackage-repo-tool's upper bounds have to be relaxed (and that's fixed in master already).

Not sure about Ryan's case, I think he hadn't projects with both tasty and doctest. E.g. lens uses test-framework.

---

About trustee. I wouldn't use it in CI in general, and not even for tasty. If you want to use it as a library author I'd suggest you do occasional checks, e.g. before releases with more changes.

There are various small unimplemented features I'd like to have (like setting failure exit code), but most importantly: it's slow, and I don't know how to fix that (it has to rebuild a lot of stuff). For tasty it's not very bad, around one minute CPU time per compiler (clocked with GHC-7.6), given the dependencies are cached. For tasty-quickcheck (for two compilers at once):

• without --verify: user 1m53.632s. But this always succeeds, you have to check manually if there's something suspicious.
• cold cache: user 9m46.768s
• warm cache: user 2m12.192s

The big cold cache time is caused by older QuickCheck versions, which depend on stuff through semigroups. (Please don't bump lower bound of QuickCheck because of this!).

Also I don't know how to find right lower bound otherwise than by doing linear scan from the bottom which is slow for newer compilers, as it have to check many versions. On the other hand, binary search won't do it, as e.g. https://matrix.hackage.haskell.org/package/tagged has weird structure, and there are many packages with similar "not diagonal strip" matrices. One idea would be to try major versions first ==x.y.* and there is an install plan, do a linear scan on that range (cabal will probably pick greatest in that group, we want least).