stack 1.7.1 still has problems finding build tools ("The program 'happy' is required")

Created on 2 Jul 2018 · 15Comments · Source: commercialhaskell/stack

General summary/comments (optional)

hledger appveyor builds are failing due to not being able to find "happy" when building pretty-show, haskell-src-exts, language-javascript. https://github.com/simonmichael/hledger/issues/832

I saw this a month ago and tried several things to fix it, and probably thought I had solved it by upgrading to stack 1.7.1, but now it seems not.

Steps to reproduce

I don't have a short repro, instead I'll point to appveyor logs.

Expected

Successful builds of pretty-show, haskell-src-exts, language-javascript.

Actual

These packages failed to build due to "missing happy", even with stack 1.7.1. Eg see
https://ci.appveyor.com/project/simonmichael/hledger/build/master-460.

Some more details:

hledger build history: https://ci.appveyor.com/project/simonmichael/hledger/history.
Only the full, >30m builds are building pretty-show etc.

The last full build that succeeded was https://ci.appveyor.com/project/simonmichael/hledger/build/master-451 on 26 May. The stack version is not reported, but it fetched http://www.stackage.org/stack/windows-x86_64, and stack 1.7.1 was released on 27 Apr, so I would have thought it was using stack 1.7.1. Unless there was some path issue.

The next full build, 456 on 30 May, failed with No packages found in snapshot which provide a "happy" executable, which is a build-tool dependency of "pretty-show" warnings and The program 'happy' version >=1.19 is required but it could not be found errors. So did build 460 and later, and these report the stack version as definitely 1.7.1. https://ci.appveyor.com/project/simonmichael/hledger/build/master-460.

Builds 459, 462 and 465 were non-full builds that succeeded by luck, appveyor apparently picks randomly from several build instances each with their own cache state.

Stack version

1.7.1

Method of installation

Official binary, downloaded from stackage.org or fpcomplete's package repository

build extensible-snapshots further investigation required need confirmation bug

Source

simonmichael

Most helpful comment

As part of #3922, I was discussing the behavior of the build tool detection with @bitemyapp. It might make sense to copy the behavior that cabal-install 2.0 (or 2.2?) added for build tool detection, which unless I'm mistaken comes down to something like:

For new cabal files, build tools must be specified including the package they come from
For old cabal files, there's a hard-coded mapping from build tool name to the package it comes from

That would likely bypass many cases where it becomes difficult/impossible to determine which package was intended, as well as allow us to much more lazily parse cabal files (since we needn't know all executables provided by all packages in a snapshot).

snoyberg on 4 Jul 2018

👍2

All 15 comments

Can you also try with the stack from HEAD? stack upgrade --git and then build again.

I think this has been solved on master, accidentally, but I'm not completely sure.

mihaimaruseac on 2 Jul 2018

I'll report back.. it's taking a while.

simonmichael on 2 Jul 2018

👍1

I can still reproduce with stack-git: https://ci.appveyor.com/project/simonmichael/hledger/build/master-497

simonmichael on 2 Jul 2018

👍1

For new cabal files, build tools must be specified including the package they come from
For old cabal files, there's a hard-coded mapping from build tool name to the package it comes from

snoyberg on 4 Jul 2018

👍2

BTW, adding an explicit stack build happy to your CI scripts _should_ be a decent workaround in the short term unless I'm mistaken @simonmichael.

snoyberg on 4 Jul 2018

Sorry, last comment for a bit: do you have any kind of local repro for this? I haven't been able to trigger it on my OS X system at least.

snoyberg on 4 Jul 2018

I don't, sorry. I don't see it on mac either, or gnu/linux.

https://ci.appveyor.com/project/simonmichael/hledger/build/master-458?fullLog=true seems to show that explicitly pre-installing happy didn't help (again unless I'm missing some path issue like a .\happy.exe, but I don't think so).

simonmichael on 4 Jul 2018

@simonmichael could you try using the 4125-cabal-style-build-tools branch of Stack and see if that fixes things for you? We'd still need to make sure this is the right solution before merging to master, but having data that it solves this bug would be great.

snoyberg on 4 Jul 2018

@snoyberg sorry but I've had trouble installing this branch of stack. I've been trying upgrade --git-branch, but this fails ("you are already running the most recent version") with stack-1.7.1 or with a recent stack-81889990.
https://ci.appveyor.com/project/simonmichael/hledger/build/master-503#L15
https://ci.appveyor.com/project/simonmichael/hledger/build/master-505?fullLog=true#L34

simonmichael on 4 Jul 2018

What I'd do would be to clone the repo and checkout the branch then stack build and stack exec stack -- <arguments>. I think this should work

mihaimaruseac on 5 Jul 2018

I _think_ that's because you're missing the --git flag, but I'm not sure. I'm forked the repo and I'm trying to kick off a build myself: https://ci.appveyor.com/project/snoyberg/hledger

snoyberg on 5 Jul 2018

Doh, you're right. ~~https://ci.appveyor.com/project/simonmichael/hledger/build/master-511 might show what we want.~~

simonmichael on 5 Jul 2018

It looks to me like my AppVeyor build didn't have this bug. The build failed, but that seems to be for an unrelated reason (maybe a timeout?). Can you confirm @simonmichael?

snoyberg on 5 Jul 2018

Your latest looks good! And mine too.
https://ci.appveyor.com/project/snoyberg/hledger/build/1.0.3?fullLog=true
https://ci.appveyor.com/project/simonmichael/hledger/build/master-512?fullLog=true

simonmichael on 5 Jul 2018

So I gather that #4132 solves this, :+1:

mihaimaruseac on 5 Jul 2018

Was this page helpful?

0 / 5 - 0 ratings