stack doesn't build happy

[ndmitchell]

As per https://ci.appveyor.com/project/ndmitchell/hlint/build/1.0.51, I am building haskell-src-exts, and that has a build-tool of happy, but cabal says:

setup-Simple-Cabal-1.22.4.0-i386-windows-ghc-7.10.2.exe: The program 'happy'
version >=1.19 is required but it could not be found.

It seems happy is no longer being automatically installed, as I can't find any logs for building happy. Or is happy installed from binary? If so, does the PATH need adjusting to find it?

[ndmitchell]

BTW, this used to work, so is either a regression, or a change in my build script that breaks it (but I think stack should be doing it for me, meaning I couldn't break it).

[mgsloan]

Hmm, strange! Could be related to #1366 (comment)

For me, it built and installed happy when I did

• stack init --resolver lts-3.15
• Added haskell-src-exts-1.17.0 to extra-deps
• stack build

[ndmitchell]

On my Windows system I did where happy, renamed them all to -happy.exe, did stack upgrade --git, then in a checkout of haskell-src-exts I did stack init --solver then stack build. Stack didn't try and build happy, and died with the same error messages I got above. This is reproducing on an entirely different machine to the Appveyor one, so it seems to reproduce, at the very least on Windows.

@mgsloan, are you sure you didn't already have happy on your PATH? Or perhaps you already had haskell-src-exts compiled and just copied it this time?

[ndmitchell]

For info, I believe this is a regression, because this was the first thing I ever tried with stack (as it answers a long-standing hlint issue), and it worked back then.

[yamafaktory]

Get the same issue (happy is required but not found) when trying to compile some simple examples with reflex and GHCJS. Did a stack upgrade --git before too.

[borsboom]

It looks like this is related to the resolver. When a nightly or lts resolver is used, happy does get installed. However, when a the ghc resolver is used, it does not get installed (and adding happy to the extra-deps doesn't help).

[borsboom]

The crux of the problem appears to be here, including the comment:

    -- TODO Currently, this will only consider and install tools from the
    -- snapshot. It will not automatically install build tools from extra-deps
    -- or local packages.
    toolMap = getToolMap mbp0

@snoyberg, since that TODO is yours, do you have any thoughts? Would it make sense to add extra-deps or local packages to the MiniBuildPlan (I'm not sure where else that's used), or would it be better to find another way to pass that info into getToolMap?

Aside from that, for @ndmitchell's use case, we'd also need to have stack init --solver add happy to the extra-deps.

[borsboom]

This appears to be a duplicate of #595.