Be smarter about --no-load?

[mitchellwrosen]

I think I found an odd corner-case whose symptoms look like:

Loading stack ghci --test --no-load --ghci-options=-fno-code ...
foo-0.1.0.0: Test running disabled by --no-run-tests flag.
Configuring GHCi with the following packages: foo
GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help

No files loaded, GHCi is not working properly.
Command: stack ghci --test --no-load --ghci-options=-fno-code

The problem here is I do have a .ghci, but it just has some :set -XOverloadedStrings boilerplate, and doesn't actually :load anything.

So, ghcid is passing --no-load because it incorrectly assumes my .ghci will load some modules. This can be worked around with a --command of course, but I wonder if the current behavior could be improved?

Thanks!

[ndmitchell]

It's not an odd corner case, it's by design. Typically both Cabal and Stack are pretty poor at putting the right things in scope at the right time - sometimes because they can't possibly have that information. To workaround that I let people who care about doing better supply a .ghci file which does it all by hand.

If you really just want OverloadedStrings on, and only at the prompt, why not put it in a system-wide .ghci file? That way ghcid won't stumble on it and all your ghci prompts will work as you want them to.

[mitchellwrosen]

Ah, I see. Sounds good.

[mgsloan]

Right, using --no-load does allow you to be more selective. However, stack ghci has pretty reasonable semantics for what it loads - all the modules in the components specified. Unfortunately this gets a bit squirrely with Main modules and extensions and such. stack ghci will let you know when extensions settings may conflict, though.

stack ghci will be great to work with, with regards to selective loading, once @mitchellwrosen 's suggestion here is implemented: commercialhaskell/stack#1361

Also, note that you'll really want --no-build on all but the first invocation of stack ghci. stack ghci invokes build so that cabal initializes various autogenerated files. Unfortunately, this initialization doesn't seem to be possible from the Cabal CLI. Resolving this is tracked by commercialhaskell/stack#1364

[mitchellwrosen]

@mgsloan Just curious, is there GHCi command to load all modules of all components? Or is that a stack-specific feature of stack ghci?

[mgsloan]

ghci isn't aware of stack or cabal. https://github.com/chrisdone/intero will likely be stack aware and allow loading modules based on components.

[mitchellwrosen]

Ah, of course! Thanks.