We can keep the opam/dune build around, if it’s helpful. The primary advertised and supported way would be the dune-only build. This is to have the simplified DX for new contributors and newcomers to OCaml in general.
However, to get to a point where we can merge this, there’s a bunch of open tasks and concerns (documented in the PR) that need to be resolved.
We’re also looking into using the stable version of Dune for the regular build, and running a daily CI action for the Developer Preview, instead of what the patch currently does.
The intent is to simplify the build and deployment setup.
I’m obviously in favour of having a simpler developer experience for OCaml.org, but it seems important to keep the stable opam mechanism around. And the same metadata (the opam files) are used for both tools, so it would be a useful regression test to make sure they both install the same site.
When is the “preview” part of the Dune Developer preview going to be dropped and it merged into the mainline? As far as I can tell, it involves two environment variables and not a code fork, so it seems close…
I’d welcome correction from those who know better, but, AFAIU: the preview is already built out of the trunk, as you note. What is provided in the dev preview is “nightly” builds of properly configured binaries. This allows
users to get the latest versions of the properly configured dune for package management, faster than is available in thru the existing release cycle for the mainline, and without having to detour thru opam and building locally
devs to ship changes rapidly, to receive faster feedback from adventurous users
edit: this doesn’t answer you main question, tho! We should have the requirements for shipping this as the default configuration documented somewhere. I’d welcome a pointer to that if anyone has it handy, and will report back if I find it first.
We might be very close to being able to build projects containing a dune.lock/ with opam dune 3.19.1, but I don’t think this is possible at the moment.
$ dune build
File "dune.lock/lock.dune", line 17, characters 1-21:
17 | (solved_for_platforms
^^^^^^^^^^^^^^^^^^^^
Error: Unknown field "solved_for_platforms"
My guess is that it’s probably pending a release with some ongoing change of format?
As part of the maintainers of the Dune Developer Preview, I will and try to expand a bit on @shonfeder answer.
Dune Developer Preview is a nightly build of Dune’s main branch with all the experimental Dune Package Management features activated by default. However, regarding package management itself, the small set of features needed to support building project with it is already in opam. You have access out-of-the-box to package management since dune.3.16.0 and to OCaml Toolchain (the possibility to install OCaml compilers) since dune.3.17.0.
The other package management features provided by the Dune developer preview are protected by compilation feature flags (and actionable at runtime with environment variables). They are experimental Dune features that we want users to test but that are not stable enough to land enabled in the opam version. It includes:
A change in the format of the build progress (cargo-like format), actionable by export DUNE_CONFIG__PKG_BUILD_PROGRESS=enabled,
The possibility of installing OCaml Platform Dev Tools, actionable by export DUNE_CONFIG__LOCK_DEV_TOOL=enabled and,
The new lockfiles format allowing developer to have their lockfiles portables between systems, actionable by export DUNE_CONFIG__PORTABLE_LOCK_DIRS=enabled. @gridbugs wrote a detailed post about it.
This flags are available in the FAQ section but I agree this is not clear and we should be more explicit about the experimental features
On the binary side, we are considering to build stable versions of the binaries so people can have a standalone binary of Dune.
You guessed well The new portable lockfiles describe above is currently under test and not available in the opam version. It will be available in dune.3.20.0 under the condition of setting the environment variable.
The stable format is supported by the developer preview but the developer preview format is not supported by the opam
Should OCaml.org use the old but not portable format?
Sorry, in retrospect I realize the error I posted wasn’t very clear. This was form another project (not ocaml.org) where I was testing compatibility between the two dunes (nightly and 3.19.1 without env vars). I think the format at the tip of ocaml.org PR has the old format at the moment ((expanded_solver_variable_bindings ...)).
The new portable lockfiles describe above is currently under test and not available in the