New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
simonmichael opened this Issue Jul 2, 2018 · 15 comments

Comments

Projects
None yet
3 participants
@simonmichael
Contributor

simonmichael commented Jul 2, 2018

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. simonmichael/hledger#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.

Possibly related:
#595
#3178
#3249

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

@mihaimaruseac

This comment has been minimized.

Contributor

mihaimaruseac commented Jul 2, 2018

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.

@simonmichael

This comment has been minimized.

Contributor

simonmichael commented Jul 2, 2018

@simonmichael

This comment has been minimized.

Contributor

simonmichael commented Jul 2, 2018

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

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jul 4, 2018

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

This comment has been minimized.

Contributor

snoyberg commented Jul 4, 2018

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

This comment has been minimized.

Contributor

snoyberg commented Jul 4, 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.

@simonmichael

This comment has been minimized.

Contributor

simonmichael commented Jul 4, 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).

snoyberg added a commit that referenced this issue Jul 4, 2018

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jul 4, 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 added a commit that referenced this issue Jul 4, 2018

snoyberg added a commit that referenced this issue Jul 4, 2018

@simonmichael

This comment has been minimized.

Contributor

simonmichael commented Jul 4, 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

@mihaimaruseac

This comment has been minimized.

Contributor

mihaimaruseac commented Jul 4, 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

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jul 5, 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 added a commit that referenced this issue Jul 5, 2018

@simonmichael

This comment has been minimized.

Contributor

simonmichael commented Jul 5, 2018

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

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jul 5, 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?

@mihaimaruseac

This comment has been minimized.

Contributor

mihaimaruseac commented Jul 5, 2018

So I gather that #4132 solves this, 👍

snoyberg added a commit that referenced this issue Jul 9, 2018

Merge pull request #4132 from commercialhaskell/4125-cabal-style-buil…
…d-tools

Use a hard-coded tool dependency map (fixes #4125)

snoyberg added a commit that referenced this issue Aug 13, 2018

Revert to GHC 8.2/LTS-11, use a custom snapshot
Note that the previous workaround for #4125
should no longer be necessary because:

1. Stack 1.9 will not suffer from that bug
2. To my knowledge, custom snapshots never suffered from that bug

Guess we'll find out when Travis takes a crack at this though!

snoyberg added a commit that referenced this issue Aug 13, 2018

Use a custom snapshot
This bumps us to newer versions of some libraries, in particular
conduit, which were previously blocked by #4125.
Using a custom snapshot should allow this by bypassing that bug.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment