Fix two issues when starting the repl

[mpickering]

Issue 1: In 3.14 there was a poor error when starting a repl in a project context without any targets. In 3.16, this error regressed, so cabal just exited cleanly.
Issue 2: The repl was broken when started from a global context.

Issue 1 is fixed by checking to see if there are any user targets, and issuing a proper error if there are none.

Issue 2 is fixed by specifying the correct fake target which is constructed when starting the repl in the global context.

Both are reported in #11107 and fixed in this patch.

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[ulysses4ever]

Thanks a lot!

I imagine people may get a little upset about not being able to avoid specifying a target in the project context. But it's a reasonable approach, I agree. I suppose, an alternative would be to default to the first package in the list of packages in the project file (and then there is some defaulting algorithm to pick a target in that package, I assume)? In that case (unlike with defaulting to the alphabetically first), you can reorder packages in that list and put the more important one first for convenience of being able to say just cabal repl.

Another thought: is multi-repl not up to solve this explicit-target requirement because it still has to default to some target to pick the "active" target? (And also multi-repl isn't universally available across GHC versions.)

I don't want to go deep down the rabbit hole of picking The Best™ default, just wanted to make sure we considered alternatives.

[Mikolaj]

Is this a sufficiently breaking change that we want this in 3.18, not in 3.16? If so, let's set the don't-backport label so that we don't forget.

Edit; I mean, user-workflow breaking, mostly, not API-breaking.

[mpickering]

I don't think it is breaking any existing workflows. Which ones do you have in mind?

[geekosaur]

Is this a sufficiently breaking change that we want this in 3.18, not in 3.16? If so, let's set the don't-backport label so that we don't forget.

If anything, it's the bug this fixes that is breaking workflows.

[ulysses4ever]

@Mikolaj let's review the facts:

• this is a cabal-install-only change
• it fixes an important regression in 3.16.0.0 that broke cabal repl out of project completely (cabal repl (more or less) silently fails since 3.16.0.0 #11107)
• it also streamlines the in-project behaviour of cabal repl, which seems to have been broken for a while now too, see cabal repl other-package doesn't open repl #7963 (which I just discovered and where you opined!), and improves error messaging (Internal error message for cabal repl within project scope #10527)

Overall, I think it should be included in 3.16.1.0.

[mpickering]

You can see the behaviour now in the ReplProjectTargetOnePkg and ReplProjectTargetTwoPkg tests which were diligently added by @philderbeast

With 3.14 in the ReplProjectTargetOnePkg test we get the internal error:

[nix-shell:~/cabal-sam/cabal-testsuite/PackageTests/ReplProjectTargetOnePkg]$ /nix/store/diig4i6ln0ia8xvv4kqs99klpjhlpzfl-cabal-install-3.14.2.0/bin/cabal repl
Configuration is affected by the following files:
- cabal.project
Resolving dependencies...
Error: [Cabal-7076]
Internal error when trying to open a repl for the package fake-package-0. The package is not in the set of available targets for the project plan, which would suggest an inconsistency between readTargetSelectors and resolveTargets.

In 3.16 we get

[nix-shell:~/cabal-sam/cabal-testsuite/PackageTests/ReplProjectTargetOnePkg]$ cabal repl
Resolving dependencies...

[nix-shell:~/cabal-sam/cabal-testsuite/PackageTests/ReplProjectTargetOnePkg]$ 

With this patch we get:

[nix-shell:~/cabal-sam/cabal-testsuite/PackageTests/ReplProjectTargetOnePkg]$ /home/matt/cabal-sam/dist-newstyle/build/x86_64-linux/ghc-9.12.2/cabal-install-3.17.0.0/x/cabal/build/cabal/cabal repl
Warning: this is a debug build of cabal-install with assertions enabled.
Error: [Cabal-7076]
Please pick a single [package:][ctype:]component (or all) as target for the REPL command. The packages from which to select a component in 'cabal.project', the implicit default as if `--project-file=cabal.project` was added as a command option, are:
 - pkg-one

---

For the -b case in a global context:

3.14

[matt@nixos:/tmp/tmp.EWJMmdYAt8]$ echo ":m +Data.Map" | /nix/store/diig4i6ln0ia8xvv4kqs99klpjhlpzfl-cabal-install-3.14.2.0/bin/cabal repl -b containers 
Resolving dependencies...
Build profile: -w ghc-9.12.2 -O1
In order, the following will be built (use -v for more details):
 - fake-package-0 (interactive) (lib) (first run)
Configuring library for fake-package-0...
Warning: No exposed modules
GHCi, version 9.12.2: https://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /tmp/cabal-repl.-1228985/setcwd.ghci
ghci> ghci> Leaving GHCi.

With 3.16

[matt@nixos:/tmp/tmp.EWJMmdYAt8]$ echo ":m +Data.Map" | cabal repl -b containers 
Resolving dependencies...
panic: targets should be non-empty
CallStack (from HasCallStack):
  error, called at src/Distribution/Client/CmdRepl.hs:366:38 in cabal-install-3.16.0.0-3utREsXpsFA39fm2lxvSkN:Distribution.Client.CmdRepl

With this patch:

[matt@nixos:/tmp/tmp.EWJMmdYAt8]$ echo ":m +Data.Map" | /home/matt/cabal-sam/dist-newstyle/build/x86_64-linux/ghc-9.12.2/cabal-install-3.17.0.0/x/cabal/build/cabal/cabal repl -b containers 
Warning: this is a debug build of cabal-install with assertions enabled.
Resolving dependencies...
Build profile: -w ghc-9.12.2 -O1
In order, the following will be built (use -v for more details):
 - fake-package-0 (interactive) (lib) (first run)
Warning: this is a debug build of cabal-install with assertions enabled.
Configuring library for fake-package-0...
Warning: this is a debug build of cabal-install with assertions enabled.
Warning: No exposed modules
GHCi, version 9.12.2: https://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /tmp/cabal-repl.-1229488/setcwd.ghci
ghci> ghci> Leaving GHCi.

[mpickering]

To summarise:

• Case 1, there is now a proper error message, rather than "internal error".
• Case 2, the behaviour is the same as before

What has been omitted from @philderbeast's work is he always changed the default in the case that there was just one "package". I omitted that as it changed the behaviour, but we can easily modify that as well with this patch (modify the part which throws the new error to instead return a specific selector).

[mpickering]

Thanks a lot!

I imagine people may get a little upset about not being able to avoid specifying a target in the project context. But it's a reasonable approach, I agree. I suppose, an alternative would be to default to the first package in the list of packages in the project file (and then there is some defaulting algorithm to pick a target in that package, I assume)? In that case (unlike with defaulting to the alphabetically first), you can reorder packages in that list and put the more important one first for convenience of being able to say just cabal repl.

Another thought: is multi-repl not up to solve this explicit-target requirement because it still has to default to some target to pick the "active" target? (And also multi-repl isn't universally available across GHC versions.)

I don't want to go deep down the rabbit hole of picking The Best™ default, just wanted to make sure we considered alternatives.

I didn't want to get into this kind of thing for a bug-fix but my changes make it easier to experiment with these questions in future. I think @philderbeast was interested as well in this question.

[ulysses4ever]

Thanks for addressing my comments!