cabal new-run foo should default to exe:foo (same for test and bench)

[nomeata]

If I have a project foo.cabal that defines both a library and an executable named foo, which is a common situation, then currently

$ cabal new-run foo -- some args

complains that it does not know whether I want to run foo the library or foo the executable, and makes me write

$ cabal new-run exe:foo -- some args

I see how this behavior makes sense for cabal new-build etc, but I do not even know what it means to cabal new-run a library. And even if that makes sense, I believe the ambiguity should just be resolved to the executable by default.

[23Skidoo]

@fgaz, can you take a look at this? I think that old-run doesn't have this problem.

[fgaz]

Yup, old cabal works. cabal new-run without an explicit target also works.

[fgaz]

The problem is that the target resolution happens before any new-run code.

The Distribution.Client.TargetSelector:matchTargetSelector function isn't aware of the command and can't filter the targets depending on it.

If no explicit targets are specified, that function doesn't get called at all because, up in the call stack, resolveTargetSelectors matches on [] and returns TargetImplicitCwd which then can be filtered by CmdRun.hs.

If we want to fix this we probably want to pass the action directly to readTargetSelectors in every Cmd*.hs. But then what do we pass? A TargetAction? Then we'll have to add a RunAction and do some refactoring. Another action type?

Or maybe we should pass a filtering function like we do in runProjectPreBuildPhase.

[ezyang]

My suggestion is to add another parameter, but don't try very hard to make it general. Like it could just be data WhichTargets = AllTargets | ExeTargets. If you figure out there's a better thing to do later we can refactor again.

[hvr]

Does the same issue occur for new-test and new-bench?

[fgaz]

Yes. All new-* commands have this issue

[fgaz]

@ezyang as per #4602 (comment), this probably needs a general solution now