Coming late to this but I wanted to note that dune is certainly not an early winner. Coming from over 15 years of development of OCaml with complex builds and dependency it’s hard to overstate how much better the current situation is.
I have tried makefile, oasis and many others. I have also participated and witnessed the effort to port OCaml requirements inside the debian package system. This was and is still pretty complex.
dune is vastly superior because it remains simple for simple projects and abstracts away a lot of the complexity needed to understand how OCaml binary files are created and combined.
One of my favorite motto in programming is “simple things should be simple but complex things should be possible.” Dune is simple but you can still use more complex solutions of you want.
(Note that for our project we actually ditched a complex makefile/configuré system for dune. It was hard to fit the tool within our complex system but we have zero regret)
As for opam, I don’t know if any of y’all remember or have ever been adding packages to GODI but it’s also hard to overstate how much opam has improved things there as well. Much appreciation for the work that was done before but, here too, opam certainly is not an early winner…
Lastly, for both opam and dune, there is an incredible community effort to be reactive to package changes, maintain a robust CI, coordinate changes between the builder and the package manager and more. I have nothing but mad respect for this and, perhaps, this human side of it is the most important asset for the platform as well.
All true, but I think @xavierleroy fairly characterizes the concerns registered here in this thread by the following message posted on another thread:
What is at issue here is not really about making simple things easy, which I think we all agree opam and dune taken together do a decent job with today, but rather with ensuring the complex things remain possible, which would be at risk if dune and opam were merged into a unified tool with only the opaque library interfaces between them in regular maintenance.
I think everyone should want dune to be usable with whatever alternatives to opam that project developers want to target, e.g. nix, FreeBSD pkg, Ubuntu apt, et cetera. Likewise, I think everyone should want opam to be usable with whatever alternatives to dune that application packagers what to use, e.g. make, bazel, b0, et cetera.
As Xavier suggests, it should not be a problem to experiment in developing something that provides a unified CLI capable of driving both opam and dune together. The problem would arise if the opam and dune tools were to stop being usable independently because only their core libraries were actively maintained as parts of the unified driver tool, while the other CLI tools were left to decay.
Accordingly, it’s a bit of a problem to position the experiment to develop a new addition to the software ecology as an effort to simplify the language toolset, unless you’re going to be explicit about abandoning the parts of the ecology that the new addition is meant to make obsolete.
I can’t agree they do a decent job today. I appreciate that Dune is better than other tools available for OCaml, but that doesn’t mean it is adequate or good. The problem is that the doc is so poor I can’t tell whether it is good or not. The only thing clearly explained is how to set up an empty project with no dependencies.
My understanding is that this is a well known problem. And I’m hopeful the doc will be vastly improved and someday I’ll be able to read it, try the features I currently can’t figure out, and then agree that Dune + Opam is decent for common workflows. But without this, I think very few new users would come to that conclusion.
I think that only after the current doc problem is addressed would it be possible to see if the current workflows are inadequate for new users, and determine whether new workflows (including a combined dune/opam tool) are needed. And only after that would it make sense to start worrying about whether the doc for the lower level tools might suffer because they’re neglected, or that doing complex things might become impossible.
It just occurred to me that if the new workflows described in the roadmap are an attempt to “fix” the old workflows, then maybe the old workflows are considered so messy/complex that they can’t be documented clearly, and the only way forward is to create new workflows. Is that the case?
From what I heard the stack slowly loses traction these days. Seems that they will arrive at the similar situation with one blessed buildsystem and that’s it.