Cabal: `cabal repl` fails on package with Library and Executable

[amigalemming]

i have a package containing a library and two executables. I want to run ghci with all library modules loaded. But I get:
~~
$ cabal repl
cabal: The 'repl' command does not support multiple targets at once.
~~
Package tested: http://hackage.haskell.org/package/med-module
As far as i can judge this problem is new in Cabal-2.0.

[michalrus]

This is inconsistent with cabal repl --help:

[…]

Usage: cabal repl [COMPONENT] [FLAGS]

[…]

The default component is the library itself, or the executable if that is the
only component.

[…]

And it broke https://github.com/michalrus/intero-nix-shim. :smiley: I’ll do a workaround there for the time being.

[zcesur]

I've been having the same issue ever since I installed Cabal v2, and my package does not even have executables. It only has a library and a test-suite.

[rzetterberg]

A temporary workaround for this problem is to add a flag to your cabal that you can mark the executables as Buildable: false so that there is only one target left, the library. I didn't find a way to select the library only from the command line arguments, so I used this workaround.

First I added the flag above the targets in my cabal file:

Flag library-only
    Default:       False

Then I added a conditional for each target that check the flag, like this:

executable myapp
  if flag(library-only)
    Buildable: False

Then before running cabal repl I ran:

cabal configure -flibrary-only

Then I could successfully run cabal repl to only use the library :1st_place_medal:

[kapralVV]

I have the same issue. The commands below work correctly
cabal repl exe:<name>
cabal repl test:<name>

however I cannot run
cabal repl
_cabal: The 'repl' command does not support multiple targets at once._
OR
cabal repl lib
_cabal: Unknown build target 'lib'._

But in cabal repl --help we can see

Examples:
  cabal repl               The first component in the package
  cabal repl foo           A named component (i.e. lib, exe, test suite)

So according to it lib COMPONENT should be valid target as well

[mitchellwrosen]

@kapralVV This works:

cabal repl lib:<name>

[dmjio]

Would be nice to just allow cabal repl lib, since afaik only one lib is allowed.

[hvr]

@dmjio what do you mean by "only one lib is allowed"?

[dmjio]

@hvr I mean, only one public library is allowed to be defined per package. So when cabal repl is invoked, it would be nice to default to the public library.

[dmjio]

@hvr, I suppose cabal new-repl has this behavior.

[23Skidoo]

I mean, only one public library is allowed to be defined per package.

Note that this restriction will be going away soon (this is what @fgaz's GSoC project is about).

[hvr]

While this ticket is about the soon to be obsolete (old)-repl semantics; things get a lot more interesting in the new-repl paradigm, where the decision which component to load needs to take into account a multi-package situation.

We have a related design issue with the semantics of which set of goals an implicit (i.e. w/o any explicit target selectors) cabal new-build expands into. There we currently default to using the package that's currently in $CWD as the implicit target goal; and if there isn't any package in the current $CWD, we ask the user to disambiguate.

This would naturally extend to an implicit cabal new-repl, which should pick a default goal if and only if there's an obvious and unique(!) choice inferrable from $CWD, and if it isn't unique, ask the user to disambiguate/clarify. A related design issue concerns cabal new-run which faces a similiar design issue (#4676). We should make sure that all these sub-design choices result in an overall consistent design of all new-* commands to reduce confusion.

[fgaz]

@typedrat is this fixed by #5461?

[typedrat]

Nope, but only because it spaced my mind. Fixed now. 👍

[dmead]

this breaks haskell-mode yes?

[hvr]

@dmead can you elaborate please? are you saying that b2a479510f4e93406d9b90701424b2d42110da99 is causing problems for haskell-mode?