Skip to content

stack setup claims to be using a sandboxed GHC when using a system-wide one #2963

@Blaisorblade

Description

@Blaisorblade

General summary/comments (optional)

stack setup can claim to be using a sandboxed GHC when in fact using a system one. I think it's a regression and this used to work (at a time when system GHC was the default).

Steps to reproduce

  1. Install a system-wide GHC (e.g. 8.0.2.)
  2. Pick a compatible resolver (e.g. nightly-2017-01-31)
  3. Run stack setup --system-ghc --resolver $resolver, e.g.
$ stack setup --system-ghc --resolver nightly-2017-01-31
stack will use a sandboxed GHC it installed
For more information on paths, see 'stack path' and 'stack exec env'
To use this GHC and packages outside of a project, consider using:
stack ghc, stack ghci, stack runghc, or stack exec

My config.yaml:

install-ghc: false
ghc-options:
  "*": -j3

(I also had system-ghc and newer-minor enabled there, but the bug appears with them disabled, too).

Expected

I expected stack to tell me it's using a system-installed GHC.

Actual

Stack claims it's using a sandboxed GHC.

Verbose output

$ stack setup --system-ghc --resolver nightly-2017-01-31 --verbose
Version 1.3.2 x86_64 hpack-0.15.0
2017-01-31 22:04:25.145277: [debug] Checking for project config at: /Users/pgiarrusso/AeroFS/Repos/stack-bluevelvet/stack.yaml
@(Stack/Config.hs:863:9)
2017-01-31 22:04:25.146516: [debug] Loading project config file stack.yaml
@(Stack/Config.hs:881:13)
2017-01-31 22:04:25.150348: [debug] Trying to decode /Users/pgiarrusso/.stack/build-plan-cache/x86_64-osx/nightly-2017-01-31.cache
@(Data/Store/VersionTagged.hs:68:5)
2017-01-31 22:04:25.170540: [debug] Success decoding /Users/pgiarrusso/.stack/build-plan-cache/x86_64-osx/nightly-2017-01-31.cache
@(Data/Store/VersionTagged.hs:72:13)
2017-01-31 22:04:25.183141: [debug] Getting system compiler version
@(Stack/Setup.hs:370:17)
2017-01-31 22:04:25.183866: [debug] Run process: /usr/local/bin/ghc --info
@(System/Process/Read.hs:306:3)
2017-01-31 22:04:25.363289: [debug] Process finished in 179ms: /usr/local/bin/ghc --info
@(System/Process/Read.hs:306:3)
2017-01-31 22:04:25.367814: [debug] Performing a sanity check on: /usr/local/bin/ghc
@(Stack/Setup.hs:1495:5)
2017-01-31 22:04:25.367968: [debug] Run process: /usr/local/bin/ghc /private/var/folders/_7/hlxv4yv95x95vgnn416b4q4m0000gp/T/stack-sanity-check76911/Main.hs -no-user-package-db
@(System/Process/Read.hs:306:3)
2017-01-31 22:04:26.143417: [debug] Process finished in 775ms: /usr/local/bin/ghc /private/var/folders/_7/hlxv4yv95x95vgnn416b4q4m0000gp/T/stack-sanity-check76911/Main.hs -no-user-package-db
@(System/Process/Read.hs:306:3)
2017-01-31 22:04:26.144330: [info] stack will use a sandboxed GHC it installed
@(Stack/SetupCmd.hs:109:19)
2017-01-31 22:04:26.144483: [info] For more information on paths, see 'stack path' and 'stack exec env'
@(Stack/SetupCmd.hs:110:5)
2017-01-31 22:04:26.144564: [info] To use this GHC and packages outside of a project, consider using:
@(Stack/SetupCmd.hs:111:5)
2017-01-31 22:04:26.144688: [info] stack ghc, stack ghci, stack runghc, or stack exec
@(Stack/SetupCmd.hs:112:5)

Stack version

$ stack --version
Version 1.3.2 x86_64 hpack-0.15.0

Method of installation

  • Homebrew package (which, apparently, is a supported approach, though the script looks scary).

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions