Update stackage snapshot we build against

[pbrisbin]

The interaction between stack and halcyon is non-obvious so this PR is partially an experiment to see if the halcyon-based CI builds OK.

In general, this changeset aims to make Carnival compatible with the latest LTS snapshot (5.0), which eases development in a stack-based environment, which I personally need if I want to tackle some of the open issues going forward.

I'd also be interested in replacing the halcyon stuff entirely with a stack-based setup (and use Docker for the Heroku deploys), so this is a step in that direction as well.

[pbrisbin]

so this PR is partially an experiment to see if the halcyon-based CI builds OK.

Your tests failed on CircleCI

Well, OK then.

[pbrisbin]

Got to the point where CI does try to run, but the integration spec fails. I suspect it's the server not running in the right environment, will investigate this week/weekend.

[jferris]

I tried to do this locally a little while ago but got tired of the 30 minute feedback cycle. I'm also on board with switching to Docker for deploying to Heroku.

[pbrisbin]

Green!

And, um, pretty fast too. Down to 8 minutes from 40, am I reading that right?

[jferris]

Green!

Noice

And, um, pretty fast too. Down to 8 minutes from 40, am I reading that right?

Wowzers. Is that because Circle's cache is more efficient than the S3 machinery we were using with Halcyon and Stack's caching is finer-grained than Halcyon snapshots?

[pbrisbin]

Yes and no.

Comparing https://circleci.com/gh/thoughtbot/carnival/214 to https://circleci.com/gh/thoughtbot/carnival/207:

stack build vs halcyon-build is 2 minutes vs 10, which I'd attribute to better caching. Halcyon does a lot of work to figure out what it should pull from S3, whereas stack just dumps and loads its working directory then does a normal build.

There's also a large difference in the two test steps: 2 minutes via stack and ~12 via halcyon (each). But, those steps seem to do the same amount of compilation, package loading, and, well, work. The stack-based one is just a lot faster. :shrug:

[jferris]

I don't really understand why the Halcyon version took so long to run the tests, but this looks good either way.

[pbrisbin]

Just realized: I think I have to guard the Applicative import-removal with CPP on GHC version, since Halcyon uses 7.8.4 by default, this code will fail to deploy, I think.

I could also fully remove Halcyon in this PR and add docker deployment (example). I could also configure Halcyon to use 7.10, but that might be a mess of constraint updates.

Open to ideas.

[jferris]

I think the best incremental option would be to get Halcyon using 7.10. I gave it a quick try earlier and the constraints do seem to be a challenge.

I think it makes sense to end up using Docker before too long, but I worry about changing too many pieces at once.

[pbrisbin]

OK. I'm good with that, and can work on it in a separate pre-requisite PR.

[pbrisbin]

Rebased. Now just updates to LTS-5.0/GHC-7.10 (with noted caveats) and fixes and enforces warnings.

[jferris]

Awesome.