Make `dune exec` pick the executable automatically when it is unambiguous

[Leonidas-from-XIV]

Desired Behavior

dune exec is an useful command for running binaries and making sure that the binaries that are run are up-to-date (thus preferable to dune build followed by _build/default/install/bin/...). However in my experience it is unnecessarily strict on what inputs it accepts when it could (in my opinion) fairly reasonably infer what the user wants to do in a number of common cases.

At the moment dune exec requires an argument. However if the project just has one (public?) executable, it would be convenient if dune exec just picked that executable automatically. My assumption here is that a lot of simple projects only have one single executable, thus this would make it easier for a lot of people as they don't need to look up and specify the executable anymore.

Example

(executable
  (public_name foo))

$ dune exec

builds and executes foo automatically.

[Alizter]

Do you think it would be useful to take a directory:

dune exec foo/
dune exec bar/

For packages with public binaries foo and bar?

That way we can just check for a package and check it produces a unique binary in order to run it.

[Leonidas-from-XIV]

I am a bit worried that provided the user has a project with a folder foo that contains bar and bar that contains foo (albeit this being a fairly contrived scenario) then shell completion might suggest dune exec foo/ and it will wrongly execute bar.

From a user perspective I am not sure if I could intuit what cargo exec <directory>/ would mean.

[Alizter]

The folder name is irrelevant here. What we are interested in in dune exec is the directory we are inspecting in order to find the unique package with a unique binary. That way dune exec as you proposed would just be dune exec . similar to dune runtest and dune exec dir/ will jut check if there is a single package in dir/, find what it is, find the binaries it produces, and run the unique one if it exists.

[Leonidas-from-XIV]

That's the point, if we make dune exec be the same as dune exec . we might make it conceptually simpler but potentially a worse UX for users because now directory names have a meaning. I think part of why the Dune CLI is not the best UX is that it tries too hard to be "conceptually right" and not enough to be helpful.

However, if others think this behavior is reasonable and helpful I am not insisting on my view. It's also good if things are conceptually understandable. In any case it it would IMHO be an improvement over the status quo.

[Alizter]

because now directory names have a meaning.

That's exactly the opposite of what I am suggesting.

[Leonidas-from-XIV]

I don't understand. Presume we have a layout with foo/bar.ml and bar/foo.ml and these are executables.

If I type dune exec foo I would get the binary in bar but if I type in dune exec foo/ I would get the binary in foo. That's quite a difference between adding or not adding a single slash.

Or am I misunderstanding your proposal?

Edit: exec not build

[Alizter]

@Leonidas-from-XIV I'm not proposing that we modify what dune build interprets. Those should still be build targets.

What I'm suggesting is a refinement of the semantics of dune exec. As you note, the only way you can run an executable is to give the path to it, or a pform that expands to that path, or the public name.

My suggestion expands this by considering directories too. So if somebody has written dune exec foo then we would try to find a public name via foo, if it can't then it would consider if it is a directory or a file.

If it is a directory then we can look for the packages in this directory such that they produce a unique bin/ entry in their install layout.

If it is a file, then we can attempt to execute that file or do some further disambiguation as you've suggested in #14511.

The example that you've given with the differing names would work in the way you've suggested, but I would argue that this is not so common and a little convoluted. What is more common is for packages to have their own subdirectories, so searching for unique binaries in those directories makes more sense.

My suggestion is not counter to your proposal of dune exec with no arguments, but rather an attempt to give it a semantics that can make sense more generally special casing to your original proposal.

However there is a serious issue with all of this and that is it only works for public binaries. So if you do dune exec mypkg/ then you might as well run dune exec mybin. My suggestion does not address private binaries, but it does allow most single package single bin projects to run dune exec . at the project root.