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

[ndmitchell]

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]

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]

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]

@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]

@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]

@achernyak all yours

[mgsloan]

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]

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

[ndmitchell]

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]

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