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

Stack ghci should start with a project, even if there are two #1068

Closed
ndmitchell opened this Issue Sep 28, 2015 · 19 comments

Comments

Projects
None yet
5 participants
@ndmitchell
Contributor

ndmitchell commented Sep 28, 2015

C:\Neil\ghcid>stack ghci
* * * * * * * *
The main module to load is ambiguous. Candidates are:
Package `ghcid' component exe:ghcid with main-is file: C:\Neil\ghcid\src\Ghcid.hs
Package `ghcid' component test:ghcid_test with main-is file: C:\Neil\ghcid\src\Test.hs
None will be loaded. You can specify which one to pick by:
 1) Specifying targets to stack ghci e.g. stack ghci ghcid:exe:ghcid
 2) Specifying what the main is e.g. stack ghci --main-is ghcid:exe:ghcid
* * * * * * * *

This error is a little annoying - it says it's not going to do anything useful, and the two ways of picking the useful behaviours are both quite annoying - they require me to remember command line flags every time. Instead, how about:

  • Always default to whichever is first in the .cabal file lexically, then people can reorder their .cabal file to indicate a preference.
  • Add a facility to add an entry to stack.yaml to record a default.
@borsboom

This comment has been minimized.

Contributor

borsboom commented Oct 6, 2015

I think a PR to make this a nicer would be welcome, although should probably have a bit of discussion before deciding on the exact solution.

@gambogi

This comment has been minimized.

Contributor

gambogi commented Nov 2, 2015

I'll take a stab at a possible solution: (the wording here would obviously need some retooling:

$ stack ghci
* * * * * * * *
The main module to load is ambiguous. Candidates are:
[0] Package `ghcid' component exe:ghcid with main-is file: C:\Neil\ghcid\src\Ghcid.hs
 1  Package `ghcid' component test:ghcid_test with main-is file: C:\Neil\ghcid\src\Test.hs
 You can specify which one to pick by:
 1) Specifying targets to stack ghci e.g. stack ghci ghcid:exe:ghcid
 2) Specifying what the main is e.g. stack ghci --main-is ghcid:exe:ghcid
 3) Choose (0, 1): 

Effectively communicate the same information and supply a prompt to choose between the options, with empty string defaulting to the first.

@ndmitchell

This comment has been minimized.

Contributor

ndmitchell commented Nov 2, 2015

@gambogi, for things like ghcid that doesn't really help. I'd still like it to not require user interaction - if it does I'll still have to write a separate script to start ghci.

@hackeryarn

This comment has been minimized.

Contributor

hackeryarn commented Dec 15, 2015

@ndmitchell I liked your original idea of setting the default in stack.yaml. I think we should modify the message to let the user know that they can set a default in stack.yaml too.

@gambogi If you have not started working on this yet, I would definitely be willing to give this one a shot.

@gambogi

This comment has been minimized.

Contributor

gambogi commented Dec 15, 2015

@achernyak all yours

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Dec 16, 2015

It seems a bit magical to me to add default targets for ghci. If such a thing is added, maybe it'd make sense to also have it affect stack build. I.e. default-targets: pkg1 pkg2, would affect both build and ghci.

I like @gambogi 's suggestion, since GHCi is interactive, it seems fine to me to ask the user for input. If the user doesn't enter (0) or (1) and just presses enter, then we should get the current behavior (load neither). The main issue with adding this interactivity is if editor integrations don't expect it. Could be good to have a flag that disables the behavior..

So, feel free to implement @gambogi 's idea, and possibly open an issue about having a default-targets setting.

Also, from the original issue:

This error is a little annoying - it says it's not going to do anything useful, and the two ways of picking the useful behaviours are both quite annoying - they require me to remember command line flags every time.

It isn't true that it isn't going to do anything useful. It's just not going to load any Main modules. So, I don't think there should be a magic default - I don't like picking something random just because the choice is ambiguous. This leads to circumstances where users aren't sure why one thing works and another does not.

@hackeryarn

This comment has been minimized.

Contributor

hackeryarn commented Dec 16, 2015

@mgsloan Thanks for the direction. I will work towards your proposed solution.

@ndmitchell

This comment has been minimized.

Contributor

ndmitchell commented Dec 16, 2015

I restart ghci maybe every 10 mins. I drop in and out of it quickly. I also use ghcid which runs it headless. Anything which requires interactive behaviour on every start up is unworkable for me.

Starting with nothing loaded is also problematic - I now have to :load the right thing, which is complex user interaction, and often different per project. With my existing .ghci scripts all this works out nicely.

@gambogi

This comment has been minimized.

Contributor

gambogi commented Dec 17, 2015

@mgsloan if that's the enter behavior it should probably appear first in the list of options (with its status as the default noted).

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Dec 17, 2015

I don't like the arbitrary feeling of "pick the first viable Main.hs". I do see the value of a sensible default, though. How about this approach to picking one:

  1. If there's only one executable component among stack ghci's targets. In other words, even if you're compiling benchmarks and tests, it will default to loading the executable Main.hs, if there's only one.

  2. Failing that, if there's only one non-library component among stack ghci's targets, pick that. I think the current logic already does this.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Dec 17, 2015

@gambogi In that case, how would the user ask for "don't load any Main.hs"?

I'm thinking the list should be ordered such that executable components come before test / benchmark.

@gambogi

This comment has been minimized.

Contributor

gambogi commented Dec 17, 2015

@mgsloan I agree with you that "don't load any Main.hs" should be an option. My point was it should be clear from the presented dialog that it is the first (and default on Enter) option.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Dec 17, 2015

Ohh, I see! Yes, I agree with that.

If we do add the defaulting, one issue is how to get back to having an interactive option. Might need a flag like --pick-main for this, argh! So, leaning towards not having a default.. But I would like to support @ndmitchell 's usecase well.

@ndmitchell

This comment has been minimized.

Contributor

ndmitchell commented Dec 18, 2015

Maybe we're going about this the wrong way. There is already a great place to put ghci specific options, namely a .ghci file. The problem is that GHC loads the .ghci file from the current directory first, so anything it does gets clobbered by the Stack .ghci file. Maybe stack ghci could run your .ghci file last, rather than first, which probably involves passing the option to ignore the .ghci file and then copying the contents onto the end of the Stack generated .ghci file. That gives me the extra-info free way of getting at what I want. Alternatively maybe the stack.yaml could have a .ghci-post section?

@hackeryarn

This comment has been minimized.

Contributor

hackeryarn commented Dec 22, 2015

For the time being I am going to add interactivity with the default being do nothing. If we decide to add additional flags later, that can be part of a separate issue.

@hackeryarn

This comment has been minimized.

Contributor

hackeryarn commented Dec 31, 2015

@ndmitchell I am trying to reproduce this right now, but can't seem to get the same message you got.

I tried both in a freshly created repo and directly in ghcid. Could you share anything extra that you did to get this behavior?

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Jan 3, 2016

I think it no longer reproduces directly due to the resolution of #1186 (comment). Now, it only defaults to loading the same things that stack build defaults to building (libraries and executables). So, to get the old behavior where Main.hs is ambiguous, you need to specify both, like stack ghci :ghcid :ghcid_test, or stack ghci --test.

@hackeryarn

This comment has been minimized.

Contributor

hackeryarn commented Jan 3, 2016

Thanks, stack ghci --test did the trick.

@mgsloan mgsloan closed this in #1598 Jan 5, 2016

mgsloan added a commit that referenced this issue Jan 5, 2016

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Jan 5, 2016

@ndmitchell There's a remaining bug before stack ghci works perfectly with ghcid: #1606

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