Stack: Travis build uses stack but doesn't download it on builds

[Blaisorblade]

The original build script build doesn't find stack when CI-ing my fork:
https://travis-ci.org/Blaisorblade/stack/jobs/145802415#L213-L217

That leads to a build failure because cabal uses the cabal file in master and selects the wrong versions of dependencies—in particular, it picks versions of binary and Cabal that both declare the same typeclass instance.

Working hypothesis: .travis.yml use stack in cabal builds, but .travis-setup.sh doesn't download it for cabal builds.

I conjecture that might work on your fork because there's stack in the build caches—since they cache the result of building stack.
But at some point this might lead to unexpected build configurations and hard-to-debug bugs.

My action plan:

1. I test my hypothesis by trying a fix to the build scripts
2. Ideally, somebody (I, if I manage) change the build to avoid storing the final binary.
3. If that works, you might want to verify my conjecture by clearing the Travis cache once and observing the build failure—or not, it's of course your call.

[Blaisorblade]

OK, I'm even more confused. Even the original builds complain that stack setup is needed because of a compiler version mismatch... yet, the main build works and mine fails
https://travis-ci.org/commercialhaskell/stack/jobs/145790909#L222-L222 vs
https://travis-ci.org/Blaisorblade/stack/jobs/145802415

I've added it as requested and I'm testing it, but that can't pick the right version of the dependencies—indeed it fails on template-haskell:
https://travis-ci.org/Blaisorblade/stack/jobs/145820993

I suspect the build only works because the cache contains the "right" versions of packages (here, binary-0.7.6.1 rather than -0.8), and that to fix this, sdist should pick one of the alternative stack configs, depending on the compiler version. EDIT: does that make any sense?

[Blaisorblade]

The problem described above _is_ true, but the build failure that we get as a consequence still makes no sense. I'm inclined to submit a PR improving the build, if it works, and leave the rest undiagnosed.

Should you enjoy debugging cabal hell, read on what I did discover.

But really, don't.

The offending instance in Cabal should be disabled:
https://github.com/haskell/cabal/blob/Cabal-v1.24.0.0/Cabal/Distribution/Version.hs#L138
yet it isn't:
https://travis-ci.org/Blaisorblade/stack/jobs/145906707
I've really got no clue what's up.

Other details: cabal also decides to install the latest integer-simple, which however requires a more recent GHC. My cabal avoids that, thankfully, by picking the text package disabling the integer-simple flag.

text-1.2.0.6 (latest: 1.2.2.1) -integer-simple (new package)

[sjakobi]

Thanks for investigating this, @Blaisorblade!

I'm embarrassed to admit that I had noticed the issue before but gave up investigating it quite quickly.

[Blaisorblade]

@sjakobi wrote:

I'm embarrassed to admit that I had noticed the issue before but gave up investigating it quite quickly.

I also don't volunteer for debugging that breakage, and I'm not sure there's hope that sdist --pvp-bounds should work . I think it'd be worth _dropping_ most manually specified bounds to try getting pvp-bounds to work more—that should guarantee success.

Meanwhile, I tried cabal-install 1.22 in #2392, and that gives up earlier: https://travis-ci.org/commercialhaskell/stack/jobs/145939682. I'm trying 1.24 now.

[Blaisorblade]

@mgsloan noticed the errors in #2392.

The error is on 7.8.4-cabal, and I think that master might already be silently broken and that is masked by the cache — cabal prefers picking the already installed packages, producing a consistent build plan, but that seems luck. But I might miss something. What do you think?

If you agree 7.8.4-cabal _is_ already silently broken, I guess you can either drop it from testing (like @sjakobi's #2273) or try to fix it (if there's a good reason). The best argument is that it tests --pvp-bounds.

I started looking at the errors but I confess I don't have the energy to fight my way through them that soon. Though it's worth trying at least --reorder-goals --max-backjumps=-1, and/or dropping current bounds from the cabal file so that pvp-bounds can do more (as mentioned in https://github.com/commercialhaskell/stack/issues/2390#issuecomment-233922712).

[sjakobi]

I also don't volunteer for debugging that breakage, and I'm not sure there's hope that sdist --pvp-bounds should work .

Indeed stack --resolver ghc-7.8.4 init --solver can't find a build plan for a stack sdist built with stack sdist --pvp-bounds both. But that's not so very surprising because the bounds are based on the versions from the default stack.yaml which uses ghc-7.10.3.

If you create the sdist with --stack-yaml stack-7.8.yaml the solver can actually find a build plan.

I think that master might already be silently broken and that is masked by the cache

So yes, that seems to be the case!

If you agree 7.8.4-cabal is already silently broken, I guess you can either drop it from testing (like @sjakobi's #2273) or try to fix it (if there's a good reason).

I'm in favor of dropping that job.

[Blaisorblade]

If you create the sdist with --stack-yaml stack-7.8.yaml the solver can actually find a build plan.

Yes, but I already fixed that (supposedly) with STACK_YAML=stack-7.8.yaml, and that failed even without cache (https://travis-ci.org/Blaisorblade/stack/jobs/145911472).

However, IIUC stack --solver uses --reorder-goals --max-backjumps=-1, so I just tried to add that, which maybe is a good idea anyway? (I'm happy to try solutions requiring O(1) work 😃 ).

Feel free to drop the 7.8 job anyway, but it might be a good test for --pvp-bounds. Or maybe one should just try to generate the build plan as you did, and as part of the integration tests. Your call.

EDIT: with those options I finally got again a build plan: https://travis-ci.org/Blaisorblade/stack/jobs/146236557
EDIT2: that plan is failing because of https://github.com/basvandijk/lifted-base/issues/31, but that's not the stack solver's fault.

[sjakobi]

EDIT2: that plan is failing because of basvandijk/lifted-base#31, but that's not the stack solver's fault.

Thanks! Addressed in https://github.com/commercialhaskell/stack/commit/8f03a887d94300d37790d2f8647a352d88217a87.

[sjakobi]

Feel free to drop the 7.8 job anyway, but it might be a good test for --pvp-bounds.

Once https://github.com/commercialhaskell/stack/pull/2322 is finished, we'll have much wider bounds anyways.

I have asked @borsboom if he needs the 7.8 cabal job but if he doesn't I'll merge https://github.com/commercialhaskell/stack/pull/2273.