Plan for "stack ghci" to properly handle different default-extensions in different components

[mgsloan]

Conflicts between extensions is the primary cause of stack ghci not working properly with a multi-package / multi-component project. This is why I added code to describe to the user the conflicts that could occur: #1270

When looking at the code for ghci (well, intero! https://github.com/chrisdone/intero), I noticed that it's actually quite feasible for us to do the following in the ghci script:

:set -XTemplateHaskell
:add Pkg1Module
:set -XNoTemplateHaskell
:add Pkg2Module

In this case, pkg1 has TemplateHaskell specified as a default-extension. pkg2 doesn't, so it gets unset before loading those modules. The tricky part of this is that these loads need to be done in dependency order.

Another approach, which will hopefully also be taken, is to solve this more completely in intero itself: https://github.com/chrisdone/intero/issues/41 . It seems reasonably feasible to have different flags for different modules. With this approach, we don't need to worry about knowing the order of dependencies as that can just be handled by normal ghc logic. On the other hand, it'd be good for stack to use vanilla ghci well too.

[cdepillabout]

I run into this occasionally. I'd be nice if stack dealt with it so I didn't have to think about it.

I often use NoImplicitPrelude for my own packages. This works fine. However, when I need to vendor a third-party package that doesn't use NoImplicitPrelude, ghci stops being able to load the third-party package.

I'm able to solve this with a .ghci file like this:

:set -XImplicitPrelude
:add .stack-work/downloaded/f92e480f2c72283808e19c78cb3f54627179ef4440ab001a3fade5e6ec94dc61/src/SomeThirdPartyPackage.hs
:set -XNoImplicitPrelude
:add src/MyPackage.hs

[mgsloan]

I believe that @AndrewRademacher intends to work on this as a continuation of #2457

[AndrewRademacher]

@mgsloan @cdepillabout , this one is is my court. Package level control of DynFlags is currently in progress. I'm planning on having this mostly worked out by the end of tomorrow.

[mgsloan]

I've recently revisited this approach. It's a good idea for getting everything to load into ghci. However, it doesn't quite work well with :reload. I think the solution is to build a new command into stack ghci, like stack ghci --output-reload-script. This will do all of the normal ghci setup and targets stuff, but instead of running ghci, just output the ghci commands to stdout. Then, intero can interpret these directly as commands. This should facilitate doing intelligent :load and :reload in intero (we may rename them, hard to say).

[domenkozar]

I was mostly avoiding this pain using ghcid.

But now with ghcide this is quite a pain, since this bug blocks usage of it.

[domenkozar]

I've opened https://gitlab.haskell.org/ghc/ghc/issues/17195