ocaml
Looking up paths to executables with dune which
The "dune exec" command has three different ways of resolving the names of executables to paths to executables:
- public executables defined in the current project
- executables in the "bin" directories of dependencies
- executables in directories listed in $PATH
This can lead to unexpected shadowing, especially in the case of executables from dependecies, as users may not be aware that one of the packages in their project's dependency cone defines an executable with the same name of an executable that's also insalled system-wide.
Short of fixing the problem for now, this change introduces a tool for helping investigate specifically which executable will be run by "dune exec". This adds a command "dune which" which prints the path to the executable.
Here's an example session using this command:
37 s@u3 ~/src/llama (main=)
+ λ dune exec --which ocamlbuild
_build/_private/default/.pkg/ocamlbuild/target/bin/ocamlbuild
38 s@u3 ~/src/llama (main=)
+ λ dune exec --which ocamlc
/home/s/.cache/dune/toolchains/ocaml-compiler.5.3.0-a3dd2a36d935a7ada272441c8543eba1/target/bin/ocamlc
39 s@u3 ~/src/llama (main=)
+ λ dune exec --which cat
/nix/store/87fck6hm17chxjq7badb11mq036zbyv9-coreutils-9.7/bin/cat
40 s@u3 ~/src/llama (main=)
+ λ dune exec --which foo
_build/install/default/bin/foo
Is this essentially dune exec -- which %{bin:foo}? I'm still for including such a feature, since not every system has which.
It is, yes, but I bet a lot of people don't know you can expand pforms like that (for example I did not know this).
Maybe this should go under describe/show? Don't think this command is going to be used enough to live at the top level tbh.
Why is the expected frequency with which a command will be used a useful metric for deciding whether to put it at the top level or not? I think it belongs at the top level because I expect this command to be used by people debugging a situation where dune ran a command they didn't expect, and for this use case it's important that the command be easy to discover.
There are other commands under $ dune describe that are no less useful for debugging, shall we promote them all to the top level as well?
The point of having a hierarchical command line is to make the commands more discoverable. If putting things under sub-commands made the CLI less discoverable, why did we introduce the hierarchy in the first place? Dune is not like git where sub-commands are their own binaries, so it was done for purely organizational purposes.
IMO, the underlying issue is that the "discoverability" of one command comes at the expense of other commands. So yes, you have made $ dune which more discoverable, but at the cost of making the user slightly more likely gloss over more useful sub-commands.
Now it could be that I'm underestimating the utility of this command, and it is going to be more useful than I'm imagning - I'll leave the decision where to put it up to you. But I do want to clarify that:
Why is the expected frequency with which a command will be used a useful metric for deciding whether to put it at the top level or not?
Is the principle we should be following. We hide scarcely used commands, and promote the ones that are often used. We group related sub-commands to avoid repeating prefixes. We optimize for the common case.
For what it's worth, something like dune [describe/show] location would also sound fine with me and dune [describe/show] is reasonably discoverable as it has existed for a while. My concern was that dune exec --option-that-does-not-exec is quite hard to notice and also remember, so I suggested dune which to reuse the familiar term from POSIX.
