That is true. We never fundamentally change the way things work with Dune. It was already possible to have virtual libraries before Dune. But to be completely fair to the people who did the work to generalize and formalise virtual libraries in Dune, there were actually some real problems to solve and work to do. For instance, if you try to use virtual libraries without Dune, it’s likely that you will have to think carefully about the installation layout of your files and the final user will have to be careful about the order in which they list their libraries at link time. This is something Dune users don’t need to think about because Dune handles all these low-level details for them.
To be clear, the majority of Dune users shouldn’t care much about this discussion. The real feature Dune provides to its users is the Dune language; a simple and high-level language to describe their project. In this language, libraries and executables are first class citizens and this allows developers to reason at a higher-level without having to think about the low-level details. Compilation commands, META files, layout of installed files, etc… simply form the assembly the Dune language compiles down to. In this regard, Dune has succeeded and it is now possible to write complex OCaml projects without knowing what is a .cmi file or what is the difference between ocamlc and ocamlopt.
Now, there are a few things we need to acknowledge. First of all, Dune is relatively young. It is only 3 years old and there were other tools and standards that existed long before it such as ocamlfind. Dune also has flaws. For instance, if your project doesn’t fit in the Dune language, then you just can’t do much. Your best bet is to come and discuss with us to see how we can move forward. While we have been thinking about this question for a while, and in particular how to provide users some sort of extensibility this is simply something we have not prioritized so far. If you are a seasoned programmer and like to have a lot of power over how your project is built, Dune can feel a bit invasive.
Finally, there are also cases where Dune projects need to be used as part of a bigger system, such as big bazel projects. In such cases, it can be valuable to have a few more tools such as ocamlfind to tie things together.
This is what this effort is all about. Acknowledging the history, bringing together people who have worked on these problems in the past and agree on a standard to make life easier for OCaml developers. And to be clear, if this standard could be just Dune then that would be great from Dune’s point of view and would make our life much easier, but that’s effectively not today’s reality. While Dune is now widely used, there are still a lot of projects that don’t use it.