pkg: general support for installing tools

[shonfeder]

The current design of dev tools requires every tool to be hard coded. This is not sustainable or elegant.

Only a few dev tools require special treatment (e.g., utop and ocamllsp ), and we cannot require code changes to dune anytime someone wants to install a new dev tool.

When there is a package p in the opam repository that provides an executable that a user wants to employt in their development environment, they should be able to run

dune tools install p

to have dune install p such that it is available to execute via dune tools exec p or to put in their path via eval $(dune tools env).

Related (but distinct) issues:

• https://github.com/ocaml/dune/issues/12135: support for :with-dev-setup is a special case of general support for dev tooling, which has its installation interface compatible with opam conventions
• https://github.com/ocaml/dune/issues/12107: installations that are available system-wide intersect with general tooling support, but is an independent concern.
• https://github.com/ocaml/dune/issues/12741: auto-installation of tooling on execution intersect with general tooling support, but is an independent concern.

[Alizter]

How do we tell if an executable is provided by a package in an opam repo?

[shonfeder]

There's not a general way of doing that (yet), at least not without fetching the sources, afaik. But that isn't required if dune tools install <p> takes a package name in the general case: it will install the tools provided by the package.

[Leonidas-from-XIV]

Personally I'd rather have tools installed via a stanza in the dune-workspace, an idea we discussed in a 1on1 with @shonfeder, something along the lines of:

(dev_tools
  (dune-release (< 2.1.0))
  (ocamllsp (and :matches-compiler (>= 1.0.0))

This also allows to add further metainformation to the tools and separates the dependencies one developer uses from the dependencies that all developers use (:with-dev-setup in dune-project). It also avoids the issue which (package) stanza to attach :with-dev-tools to and does not pollute generated OPAM files with information that isn't all that relevant to packaging.

dune tools install could edit the dune-workspace and add these items to the definition, to also provide a CL interface to this functionality.

[shonfeder]

There is no incompatibility between installation via command and via config file. Indeed, the former could be implemented via the latter, as you suggest.

IMO, it is not clear that one always wants use of dev tools to go thru persistent config changes (e.g., when just trying something).

This is a place where I think we'd be wise to follow expected paths that will make usage easiest for users.