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

init not finding GHC installed under ~/.stack #1072

Closed
eallik opened this Issue Sep 28, 2015 · 5 comments

Comments

Projects
None yet
3 participants
@eallik
Contributor

eallik commented Sep 28, 2015

~/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 comment has been minimized.

Contributor

snoyberg commented Sep 28, 2015

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 notifications@github.com 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 snoyberg added this to the P3: Optional milestone Sep 30, 2015

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Oct 1, 2015

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

@snoyberg snoyberg closed this in 1b0b453 Oct 1, 2015

@NightRa

This comment has been minimized.

Contributor

NightRa commented Oct 1, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Oct 2, 2015

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.

@eallik

This comment has been minimized.

Contributor

eallik commented Oct 2, 2015

In my case, I specified an exact version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment