I fear I may be partly responsible for the ‘killing the CLI’ part of this, as I first demonstrated a really early integrated prototype back in a Oxford OCaml Workshop presentation. Allow me to be really clear on my position here today: any CLI that is released as part of OCaml Platform tooling and has users is one we try really hard to maintain, as that CLI is very often already integrated into build scripts (and will thus break some opam packages that are already released, and we do try so hard to keep those building over time without upper bounds).
Back when I started prototyping the integrated CLI in 2017, OCaml was possibly at its lowest point in terms of the Platform tooling, since almost no industrial users actually used the publicly released tools! Jane Street had Jenga, Coq had Makefiles, Xen still used omake, the OCaml compiler itself had backed away from using ocamlbuild, and every project I talked to didn’t because they cited slow performance and difficult debuggability to the then-recommended stack of Oasis/ocamlbuild/ocamlfind. How did this happen? A fateful decision back in 2012 resulted in Oasis wrapping the ocamlbuild CLI, which in turn had a special mode that wrapped ocamlfind, and every single compiler invocation went through 5 forks before it ever got to ocamlopt.opt. If instead Oasis had instead linked to ocamlbuild as a library, we may have avoided this, but we’ll never find out. And I’m not criticising the authors of Oasis for their decision either – it was a very pragmatic one to get us past having to write direct ocamlbuild _tags files.
What I underestimated with the integrated CLI is the sheer amount of time any migrations take for downstream projects, and also what Xavier points out above about multi-language builds and the flexibility of Makefiles. So my own thinking has evolved on it too: what we need from our tools is a OCaml library interface, with the CLIs being as thin as possible. And by and large, that’s mostly how the active tools in the Platform operate today. We have a number of CLI tools that interoperate via opam-libs or the more lightweight opam-file-format. Dune itself is just vendoring in big chunks of opam for its own integration, which means that it can be upgraded with the same core logic as used in future versions of the opam CLI. Dune’s also got a library reimplementation of ocamlfind, so that it doesn’t need to shell out to that but still retains strong compatibility.
This also points to a possible good toplevel metric for the OCaml Platform: what proportion of the community are using the tools that we recommend? This proportion is clearly increasing (opam, dune, merlin, lsp-server and odoc are now widely adopted both in open source and in monolithic codebases that use OCaml), but I think we’re less clear on others like ocamlformat, dune-release vs opam-publish, and mdx. Suggestions for improvements on this metric, and for ways to measure it more systematically, are welcome.