Wouldn't it be simpler to launch commands with dune tools exec <TOOLS> with their PATH expanded with the tools that are installed? This can even be a single virtual bin folder with symlinks as you propose.

I personally find eval $(...) mess really brittle and a source of constant issues. More often than not it leads to capture of wrong PATHs, mismatched artifacts ending up in wrong places because some wrong ocamlc was executed etc. There is no good way to scope extensions to PATH, thus with eval you're one cd away from using the wrong tools in the wrong folder.

The issue with Dune installing not-yet installed tools is that the caller has no input on how this is done. So if ocamllsp calls ocamlformat and the latter is not installed, this command might stall for an undetermined amount of time to install it without any way to determine whether it will or not before executing it. I think this was one of the reasons why a Dune LSP was proposed, such that editors can inquire the status and interact with the package management using a modern API (which could also be used by command line tools if they just want to install a tool by supplying an CLI DuneLSP client).

IMO, we would like something like this, for the reasons noted in point (2) of #10964 (comment) . I understand it can be iffy to ask users to do this in their shells, but allowing other tooling to make use of this functionality seems like a reasonable and useful thing to do.

I am even more convinced that we really need this (or approximately this), and that it is part of a simple and elegant solution to several important needs, including

• pkg: installation of packages that can be used system-wide #12107
• dune tools setup to install :with-dev-setup deps #12135
• and stable editor support

This PR does not however cover the "run arbitrary executables with dune tools exec foo" described in the issue, but I'm planning to work on that soon.

I agree that this functionality is essentially orthogonal to the feature proposed here and the needs it addresses.

This was addressed via #12521

However, I will say that I prefer the solution here insofar as it would

create a new _build/_private/default/.dev-tool/bin folder, which contains executable shell scripts which calls dune tools exec $tool. This avoids polluting the PATH with each .dev-tool/$tool/$tool/target/bin

However, the core feature is in, and we can explore this can of improvement as a followup. Thanks, @art-w !