Skip to content

cabal repl fails on package with Library and Executable #4602

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
amigalemming opened this issue Jul 11, 2017 · 15 comments
Closed

cabal repl fails on package with Library and Executable #4602

amigalemming opened this issue Jul 11, 2017 · 15 comments

Comments

@amigalemming
Copy link
Contributor

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
Copy link

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. 😃 I’ll do a workaround there for the time being.

michalrus added a commit to michalrus/intero-nix-shim that referenced this issue Sep 11, 2017
michalrus added a commit to michalrus/intero-nix-shim that referenced this issue Sep 11, 2017
@zcesur
Copy link

zcesur commented Sep 12, 2017

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.

@hvr hvr added the type: bug label Sep 16, 2017
@rzetterberg
Copy link

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 🥇

@kapralVV
Copy link

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
Copy link

@kapralVV This works:

cabal repl lib:<name>

@dmjio
Copy link

dmjio commented Jun 5, 2018

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

@hvr
Copy link
Member

hvr commented Jun 5, 2018

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

@dmjio
Copy link

dmjio commented Jun 20, 2018

@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
Copy link

dmjio commented Jun 20, 2018

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

@23Skidoo
Copy link
Member

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
Copy link
Member

hvr commented Jun 20, 2018

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
Copy link
Member

fgaz commented Jul 27, 2018

@typedrat is this fixed by #5461?

@typedrat
Copy link
Collaborator

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

@dmead
Copy link

dmead commented Aug 7, 2018

this breaks haskell-mode yes?

@hvr
Copy link
Member

hvr commented Aug 7, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests