Error on stack ghci after stack setup in stack new environment

[hmrm]

I ran stack new to set up a project, then added a dependency to stack.yaml (hasql), and ran stack ghci. This is all on osx with stack-0.1.1.0 downloaded from github.

Penemue:project hmrm$ stack ghci
GHC version mismatched, found 7.10.1 (x86_64), but expected version 7.8.4 (x86_64) (based on r resolver setting in /Users/hmrm/Downloads/project/stack.yaml). Try running stack setup
Penemue:project hmrm$ stack setup
Downloaded ghc-7.8.4.
Installed GHC.
Would add the following to PATH: /Users/hmrm/.stack/programs/x86_64-osx/ghc-7.8.4/bin
Penemue:project hmrm$ stack ghci
Configuring GHCi with the following packages: new-template
GHCi, version 7.8.4: http://www.haskell.org/ghc/  :? for help
<command line>: cannot satisfy -package new-template
    (use -v for more information)

With verbose logging:

Penemue:project hmrm$ stack ghci -v
Version 0.1.1.0, Git revision 91fe70306f51eb3d68667a0d6e09a7d7ebbeb2b6
2015-07-03 19:04:01.741937: [debug] Checking for project config at: /Users/hmrm/Downloads/project/stack.yaml @(stack-0.1.1.0:Stack.Config src/Stack/Config.hs:489:9)
2015-07-03 19:04:01.745742: [debug] Loading project config file stack.yaml @(stack-0.1.1.0:Stack.Config src/Stack/Config.hs:512:13)
2015-07-03 19:04:01.759735: [debug] Run process: ghc --info @(stack-0.1.1.0:System.Process.Read src/System/Process/Read.hs:253:3)
2015-07-03 19:04:02.3482: [debug] Run process: ghc --numeric-version @(stack-0.1.1.0:System.Process.Read src/System/Process/Read.hs:253:3)
2015-07-03 19:04:02.50335: [debug] Run process: ghc-pkg --no-user-package-db field --simple-output Cabal id @(stack-0.1.1.0:System.Process.Read src/System/Process/Read.hs:253:3)
2015-07-03 19:04:02.569062: [debug] Run process: ghc-pkg --no-user-package-db list --global @(stack-0.1.1.0:System.Process.Read src/System/Process/Read.hs:253:3)
2015-07-03 19:04:02.619367: [info] Configuring GHCi with the following packages: new-template @(stack-0.1.1.0:Stack.Repl src/Stack/Repl.hs:69:5)
2015-07-03 19:04:02.619583: [debug] Run process: /Users/hmrm/.stack/programs/x86_64-osx/ghc-7.8.4/bin/ghc --interactive -hide-all-packages -i/Users/hmrm/Downloads/project/ -i/Users/hmrm/Downloads/project/src/ -i/Users/hmrm/Downloads/project/.stack-work/dist/x86_64-osx/Cabal-1.18.1.5/build/autogen/ -package=base -rtsopts -with-rtsopts=-N -i/Users/hmrm/Downloads/project/app/ -package=new-template -i/Users/hmrm/Downloads/project/test/ /Users/hmrm/Downloads/project/src/Lib.hs @(stack-0.1.1.0:Stack.Exec src/Stack/Exec.hs:44:5)
GHCi, version 7.8.4: http://www.haskell.org/ghc/  :? for help
<command line>: cannot satisfy -package new-template
    (use -v for more information)

[hmrm]

This was fixed by running stack build. Perhaps this issue should just be for more helpful error logging.

[snoyberg]

@chrisdone I think what we need is to blacklist loading the local packages even if they're dependencies. Does that sound reasonable?

[chrisdone]

I think this extends to the fact that any dependency that is given to GHCi needs to be installed. I wrote in another GHCi issue like this that either we filter out packages that aren't installed, avoiding this error but potentially leading to people being unable to load code, or we run an implicit build when starting ghci. The same thing happens when you load a project with a test suite but haven't ran build with tests enabled yet, the dependencies are unavailable.

In the case of local packages, you might want to just use the library version instead of loading the whole thing in. With packages parent and child, if child depends on parent but child is rather large, you can just run stack ghci child and then parent will come from the package database instead of being added as a location to load source code from. A more realistic example is ide-backend, that's impossible to load from source in combination with stack-ide because ide-backend has extensions that mess with stack-ide. But with stack ghci stack-ide I can load it in. If we ignored that local package (i.e. no -package ide-backend), I wouldn't be able to do that.

Found related ticket here: #347 (comment)

@hmrm I think the adding a hasql dependency is a red herring and just switching environment, so that your package no longer existed (and presumably you have a test suite or executable that depends on the library section of your cabal file), is what causes -package new-template to bail out.

I'm unsure whether to do the implicit build or just filter out packages. Perhaps if we said "Packages x, y, z are not installed, attempting a build (disable this with --no-auto-install) ..." then that could be a nice compromise; it'd be automatic in the default case, but if the dependencies just aren't installable for whatever reason, you could use --no-auto-install to not be prevented from starting the REPL. One of the most annoying things about cabal repl is when it refuses to start.

[chrisdone]

Or an alternative side of the same coin:

The following packages are not available and have not been added to your GHCi session's environment: x, y, z

To install the above packages, run stack build.

[chrisdone]

Closing in favour of the work-in-progress issue here: #629 Please see that for further progress on this issue.