After creating second executable, stack ghci no longer able to load library modules

[MaxGabriel]

General summary/comments

After adding a second executable, stack ghci prompts me to choose which executable I want to load (or none). Regardless of my choice, the REPL is no longer able to load modules from my library.

Meta: I haven't made many second executables in the same project before, so possibly I messed something up there? It seems pretty straightforward though and felt like a bug.

Steps to reproduce

Note: This repo has a reproduction of the issue: https://github.com/MaxGabriel/StackGhciIssue. The repo is generated from stack new stack-issue haskeleton, which is pretty barebones.

Steps:

1. Create a new stack project with an executable: stack new stack-issue haskeleton
2. cd stack-issue
3. Run stack ghci to confirm it works.
4. Add a new executable to the list like so (copied from the first executable to be identical besides the executable name and main module name):

   second-executable:
     dependencies:
     - base
     - stack-issue
     ghc-options:
     - -rtsopts
     - -threaded
     - -with-rtsopts=-N
     main: Main2.hs
     source-dirs: executable
   

5. Add a Main2.hs file to the executables directory. Copy the contents of Main.hs into it.
6. Run stack ghci

Expected

stack ghci worked, and allowed me to import modules from my library.

Actual

stack ghci asked me which executable to use, or none. Every option chosen is unable to import modules from the library. In the repo reproducing the issue, I get the error message:

Specify main module to use (press enter to load none): 1
Loading main module from candidate 1, --main-is /Users/maximiliantagher/Documents/tmp/stack-issue/executable/Main2.hs

GHCi, version 8.0.2: http://www.haskell.org/ghc/  :? for help

/Users/maximiliantagher/Documents/tmp/stack-issue/executable/Main2.hs:1:1: error:
    File name does not match module name:
    Saw: ‘Main’
    Expected: ‘Main2’
Failed, modules loaded: none.

/Users/maximiliantagher/Documents/tmp/stack-issue/executable/Main2.hs:1:1: error:
    File name does not match module name:
    Saw: ‘Main’
    Expected: ‘Main2’
Failed, modules loaded: none.

<no location info>: error:
    Could not find module ‘Example’
    It is not a module in the current program, or in any known package.
Loaded GHCi configuration from /private/var/folders/v7/5k06hq7d3wbb4cvk8smv6kl00000gn/T/ghci92913/ghci-script

When I try this in a scaffolded Yesod repo, I get a similar error message, but my modules are listed as being part of a hidden package:

<no location info>: error:
    Could not find module ‘Application’
    It is a member of the hidden package ‘mercury-web-backend-0.0.0@mercury-web-backend-0.0.0-3D8Wjw6Swy0FVZjLiDp4Vn’.

I'm able to workaround this issue in the Yesod repo by doing: stack ghci packageName:executableName, which lets me import modules from my Yesod app. I'm not able to get this workaround to work in the repo reproducing the issue, I'm not sure why.

Output of stack ghci in verbose mode, pressing enter to choose neither executable: https://gist.github.com/MaxGabriel/56e2efe78312ebc62aa4e7c319da16a2

Stack version

stack --version
Version 1.5.1, Git revision 600c1f01435a10d127938709556c1682ecfd694e (4861 commits) x86_64 hpack-0.17.1

I also tested with:

stack1.6 --version
Version 1.6.0.20171022, Git revision 7bddfaf7f9f8cd9ec1c710fa83e77262e494eee4 (5285 commits) x86_64 hpack-0.18.1

Method of installation

• Official binary

[MaxGabriel]

Ok, I traced the problem to the Main file being included by both my first and second executables. In the hpack file they both had the same source-dirs: executable line, which included both Main files. They did have different main: lines.

Once I moved my second executable's main to a different directory, then the stack behavior of letting you pick a specific executable worked fine.

[mgsloan]

I see! Yes, stack should probably support use of main / main-is stuff for this usecase.

Glad there's a workaround, though.

[MaxGabriel]

Awesome, thanks @mgsloan!

[MaxGabriel]

@mgsloan Related to this, is there any way to have a default target for stack, to avoid specifying it on the command line each time?

[mgsloan]

There is not a way to do that currently. There was some discussion somewhere, can't easily find it now, of allowing specification of default stack ghci arguments. One open question there is how to invoke stack ghci without these defaults. Maybe just stack ghci --no-default?

One approach I've used is to just create a bash alias for the ghci invocation that I tend to do.

[dahlia]

This seems to apply to tests too when there are multiple tests and they share the same source-dirs. But it's okay if one of executables and one of tests share the same source-dirs.