# Migrating OCaml.org to Use Dune (Developer Preview)

**URL:** <https://discuss.ocaml.org/t/migrating-ocaml-org-to-use-dune-developer-preview/16859>\
**Category:** Community\
**Tags:** user-feedback, ocamlorg\
**Created:** [June 20, 2025, 1:33pm UTC](https://discuss.ocaml.org/t/migrating-ocaml-org-to-use-dune-developer-preview/16859 "2025-06-20T13:33:52Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![sabine](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/sabine/32/4147_2.png) [@sabine](https://discuss.ocaml.org/u/sabine)\
**Post date:** [June 20, 2025, 1:33pm UTC](https://discuss.ocaml.org/t/migrating-ocaml-org-to-use-dune-developer-preview/16859/1 "2025-06-20T13:33:52Z")

</div>

Hi everyone,

we’re in the process of migrating [OCaml.org](http://OCaml.org) to use Dune package management (see [chore: Use Dune package management by sabine · Pull Request #3132 · ocaml/ocaml.org · GitHub](https://github.com/ocaml/ocaml.org/pull/3132)). The intent behind this is to

1. simplify the Developer Experience when building [OCaml.org](http://OCaml.org) (to enable newcomers to more easily get started contributing)
2. demonstrate and ensure that Dune package management is suitable for the production use case of running [OCaml.org](http://OCaml.org)

I would like everyone who has contributed, or would like to contribute to [OCaml.org](http://OCaml.org), to have the opportunity to try the patch and give feedback first.

So if you’re interested in helping test Dune package management on [OCaml.org](http://OCaml.org), please do check out [chore: Use Dune package management by sabine · Pull Request #3132 · ocaml/ocaml.org · GitHub](https://github.com/ocaml/ocaml.org/pull/3132), and follow the instructions in the updated docs there.

Very interested in feedback or any other related matters.

Cheers  
Sabine

---

<div class="post-metadata">

**Author:** ![octachron](https://avatars.discourse-cdn.com/v4/letter/o/49beb7/32.png) [@octachron](https://discuss.ocaml.org/u/octachron)\
**Post date:** [June 27, 2025, 12:59pm UTC](https://discuss.ocaml.org/t/migrating-ocaml-org-to-use-dune-developer-preview/16859/2 "2025-06-27T12:59:32Z")

</div>

Just to check, will it still be possible to build the site locally without using the developer preview of dune?

---

<div class="post-metadata">

**Author:** ![sabine](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/sabine/32/4147_2.png) [@sabine](https://discuss.ocaml.org/u/sabine)\
**Post date:** [June 27, 2025, 2:36pm UTC](https://discuss.ocaml.org/t/migrating-ocaml-org-to-use-dune-developer-preview/16859/3 "2025-06-27T14:36:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![avsm](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/avsm/32/6_2.png) [@avsm](https://discuss.ocaml.org/u/avsm)\
**Post date:** [June 27, 2025, 8:23pm UTC](https://discuss.ocaml.org/t/migrating-ocaml-org-to-use-dune-developer-preview/16859/4 "2025-06-27T20:23:57Z")

</div>

I’m obviously in favour of having a simpler developer experience for [OCaml.org](http://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…

---

<div class="post-metadata">

**Author:** ![shonfeder](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/shonfeder/32/424_2.png) [@shonfeder](https://discuss.ocaml.org/u/shonfeder)\
**Post date:** [June 28, 2025, 11:09pm UTC](https://discuss.ocaml.org/t/migrating-ocaml-org-to-use-dune-developer-preview/16859/5 "2025-06-28T23:09:58Z")

</div>

> [@avsm](#):
>
> 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.

---

<div class="post-metadata">

**Author:** ![mbarbin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/mbarbin/32/4421_2.png) [@mbarbin](https://discuss.ocaml.org/u/mbarbin)\
**Post date:** [June 29, 2025, 4:56pm UTC](https://discuss.ocaml.org/t/migrating-ocaml-org-to-use-dune-developer-preview/16859/6 "2025-06-29T16:56:29Z")

</div>

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.

```bash
$ 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?

---

<div class="post-metadata">

**Author:** ![maiste](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/maiste/32/3919_2.png) [@maiste](https://discuss.ocaml.org/u/maiste)\
**Post date:** [June 30, 2025, 8:33am UTC](https://discuss.ocaml.org/t/migrating-ocaml-org-to-use-dune-developer-preview/16859/7 "2025-06-30T08:33:22Z")

</div>

As part of the maintainers of the Dune Developer Preview, I will and try to expand a bit on @shonfeder answer.

> [@avsm](#):
>
> 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…

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](https://discuss.ocaml.org/t/portable-external-dependencies-for-dune-package-management/16767) about it.

This flags are available in the [FAQ section](https://preview.dune.build/#faq) 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.

> [@mbarbin](#):
>
> My guess is that it’s probably pending a release with some ongoing change of format?

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](http://OCaml.org) use the old but not portable format?

---

<div class="post-metadata">

**Author:** ![mbarbin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/mbarbin/32/4421_2.png) [@mbarbin](https://discuss.ocaml.org/u/mbarbin)\
**Post date:** [June 30, 2025, 9:16am UTC](https://discuss.ocaml.org/t/migrating-ocaml-org-to-use-dune-developer-preview/16859/8 "2025-06-30T09:16:07Z")

</div>

> [@maiste](#):
>
> Should [OCaml.org](http://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](http://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](http://ocaml.org) PR has the old format at the moment (`(expanded_solver_variable_bindings ...)`).

Thanks for explanation!
