init not finding GHC installed under ~/.stack

[erikkaplun]

~/code/haskell/so-frp$ stack path --bin-path
/Users/erik/.stack/snapshots/x86_64-osx/ghc-7.8.4/7.8.4/bin:/Users/erik/.stack/programs/x86_64-osx/ghc-7.8.4/bin:/Users/erik/Library/Haskell/bin:/usr/texbin:/Users/erik/.cabal/bin:/Users/erik/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/local/MacGPG2/bin

and then

~/code/haskell/so-frp$ stack init --solver --force
Writing default config file to: /Users/erik/code/haskell/so-frp/stack.yaml
Basing on cabal files:
- /Users/erik/code/haskell/so-frp/so-frp.cabal

Executable named ghc not found on path: ["/Users/erik/Library/Haskell/bin","/usr/texbin","/Users/erik/.cabal/bin","/Users/erik/bin","/opt/local/bin","/opt/local/sbin","/usr/local/bin","/usr/local/sbin","/usr/bin","/bin","/usr/sbin","/sbin","/usr/local/bin","/opt/X11/bin","/usr/local/MacGPG2/bin"]

does this make sense or is this a bug in stack?

[snoyberg]

This is just the way that Stack works, since it doesn't know in advance
which GHC to put on the path. Wrapping the call in stack exec should work.
We can discuss making the behavior better

On Mon, Sep 28, 2015, 3:52 PM Erik Allik [email protected] wrote:

~/code/haskell/so-frp$ stack path --bin-path
/Users/erik/.stack/snapshots/x86_64-osx/ghc-7.8.4/7.8.4/bin:/Users/erik/.stack/programs/x86_64-osx/ghc-7.8.4/bin:/Users/erik/Library/Haskell/bin:/usr/texbin:/Users/erik/.cabal/bin:/Users/erik/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/local/MacGPG2/bin
~/code/haskell/so-frp$ stack init --solver --force
Writing default config file to: /Users/erik/code/haskell/so-frp/stack.yaml
Basing on cabal files:

• /Users/erik/code/haskell/so-frp/so-frp.cabal
• /Users/erik/code/haskell/so-frp/.stack-work/install/x86_64-osx/ghc-7.8.4/7.8.4/share/x86_64-osx-ghc-7.8.4/wx-0.92.0.0/wx.cabal

Executable named ghc not found on path: ["/Users/erik/Library/Haskell/bin","/usr/texbin","/Users/erik/.cabal/bin","/Users/erik/bin","/opt/local/bin","/opt/local/sbin","/usr/local/bin","/usr/local/sbin","/usr/bin","/bin","/usr/sbin","/sbin","/usr/local/bin","/opt/X11/bin","/usr/local/MacGPG2/bin"]

does this make sense or is this a bug in stack?

—
Reply to this email directly or view it on GitHub
#1072.

[snoyberg]

I went ahead with implementing this change, as I couldn't think of a downside to doing so.

[NightRa]

The new behavior picks the latest ghc.
If it can't satisfy --solver with this version of ghc, will it try an older one? (the OP's use case from IRC)

[snoyberg]

I don't think we should institute such fall-back behavior, that has the potential to do stuff the user really doesn't want (could you imagine if Stack took 4 times as long to come up with a build plan, and then just GHC 7.4.2?). For the case where the user wants to use an older version of GHC, stack --resolver ghc-X.Y -- stack init --solver works. We could also add a command line argument to require a specific GHC version.

[erikkaplun]

In my case, I specified an exact version.