cabal new-repl target1 target2 shouldn't bring up GHCi prompt twice

[ezyang]

When I run cabal new-repl with two targets, what it does is first bring up GHCi for the first target, and then the second target, UNLESS they are both targets from the same package, in which case only one target is brought up.

There are some relevant TODOs in the code in elaboratePackageTargets:

        --TODO: instead of listToMaybe we should be reporting an error here
        replTargets   = listToMaybe
                      . nubComponentTargets
                      . map compatSubComponentTargets
                      . concatMap elaborateReplTarget
                      $ targets

[ezyang]

See also https://github.com/commercialhaskell/stack/issues/130

[dcoutts]

Should simply fail if two targets are given if they span different components.

FYI, I'd prefer not to go down the route of trying to pretend that ghci supports multiple packages by unioning everything together and preying (as stack does). Of course, if we can get ghci to support multiple "home" packages then that'd be nice. That said, I've no problem with revisiting the design where it loads all modules to start with, rather than letting you (but making you) load the ones you want.

[dcoutts]

@hesselink any chance you could explain in more detail the problems you have had with cabal repl?

[hesselink]

It's been a while... One that I remember was very annoying was that cabal repl would fail to launch if there were type errors (!). I think this was https://github.com/haskell/cabal/issues/1715 and it's marked as fixed. I just tried a few packages and most things seem to work. One thing I did notice is that repl doesn't do an install, which means you can't just call repl, you have to remember to do install --only-dep first. It would be nice if common use cases just did what was needed.

Regarding the discussion above: I often load two components of the same package, e.g. a library and the test suite. Additionally, I often have a development flow where I load two packages together, including their intermediate dependencies that are also part of the project. This is a very convenient flow while developing: first make a library change (in the repl), then fix all the integration issues up to the final executable (again in the repl). I can see that there are difficult details involved, but I've used it for quite a while (in stack) with a large number of packages, and never had issues :-)

[Ericson2314]

There is a class of package which are simple enough such that multi-package repl is trivial (just pass more deps and -i flags to ghci). [This ignores detecting improperly used dependencies and unexported modules but I think that's OK for now.] Can we teach Cabal to recognize those case and support them?

Stack has had some form of multi-package repl for a while now, so it would be good to get started on that.

[jkachmar]

Is there anything that an individual contributor might be able to do to support this issue?

I've grown accustomed to stack's ability to load multiple targets at once and I'd very much like to see cabal v2-repl gain similar functionality if possible.

It's helpful most notably when working on a project with one or more test suites, so that companion tools like ghcid can reload across the whole project and run tests once compilation is green.

cc @phadej because this is a very old issue and it seems like you're the most active contributor at the moment, but if I should direct this towards someone else please let me know.

[Ericson2314]

Yes there is! Help me https://gitlab.haskell.org/ghc/ghc/merge_requests/935, which I sadly haven't attended to lately.

Everything stack does, and anything Cabal could do is a workaround. To really fix the problem is to fix GHC, and that PR goes after the bulk of the work (changing CLI etc is the victory lap).

[jkachmar]

Thanks!

I’m reading up on this GHC PR, the proposal, and some of the related issues, are you on the Haskell IRC or is there a better place to follow-up with you if I have the time or capacity to help with this?

[Ericson2314]

Sorry I was cooking and eating dinner then. Back now. Find me in #ghc.

[fendor]

@jkachmar, @Ericson2314 Just want to say that I submitted a GSOC 2020 proposal to implement https://gitlab.haskell.org/ghc/ghc/merge_requests/935 this summer