chore: bump dune version to 3.18

[maiste]

This PR is intended to be merged before #11275. The idea is to update the version of the dune lang first, as it implies new changes in terms of formatting. Then we can merge the PR that supports the maintenance fields on top of it.

cc @art-w

[maiste]

I thought it would solve the problem, but I'm not convinced because of what the CI shows. As we need < 3.17 to have access to the formatting, it means we have to upgrade the dune-project to 3.18. However, as the version is not released yet, it will break all the local switch test as they are trying to pin 3.17.2. It is like an egg-and-chicken problem. Maybe we should wait for 3.18 to be released before doing this?

[Leonidas-from-XIV]

Yeah, I think that's (unfortunately) probably the best way to go about it. Let's revisit this after 3.18.

[Leonidas-from-XIV]

@maiste I guess now that Dune 3.18 was released, we should rebase this and tackle it for 3.19.

[maiste]

@Leonidas-from-XIV, it is up for review. I have reverted the changes about the formatting as they would be part of 3.19.
(PS: I don't understand why, but it seems that the CI decided to die today.)

[Leonidas-from-XIV]

I have reverted the changes about the formatting as they would be part of 3.19.

You mean the changes to how dune files are formatted? That sounds ok to me as long as it is consistent and dune fmt doesn't reformat main.

[Leonidas-from-XIV]

I'd probably make sure that CI works (by re-running it once Github figures out its IPv6 hickups) before merging but otherwise the code looks fine to me.

[maiste]

I have almost rendered the CI green (modulo the timeout bugs). The docker image wasn't working because it was using the cache instead of using opam to fetch the new version. However, I'm struggling with the micro benchmark build using nix. Even locally, there is a conflict between the spawn version in vendor and the one installed by nix. I have seen that it already happens in the past and the fix was to disable it. I tried to, but it seems to still have the problem here. The problem occurs when lang dune >= 3.17. This is the only difference that makes it break, and I don't get why. The problem is not here when doing it without nix.

@Alizter, as you have a better understanding of nix than me, could you have an idea of what could generate the conflict in nix?

[Alizter]

I'm not sure what is going on with nix here.

I am a bit confused at the PR however. You appear to be doing two separate things at once. When we bump the dune lang version we don't typically need to bump the version of dune we require for building dune itself, i.e. the dune-project file in the repo. It should look something like this: #10459

[Alizter]

@gridbugs The version of dune in the monorepo image looks out of date. Do you know how to bump it?

[Leonidas-from-XIV]

@Alizter I think the issue is that this action

  monorepo_benchmark_test:
    name: Build monorepo benchmark docker image
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - uses: whoan/docker-build-with-cache-action@v6
        with:
          image_name: monorepobenchmark
          dockerfile: bench/monorepo/bench.Dockerfile
          push_image_and_stages: on:push
          username: ocamldune
          password: "${{ secrets.DOCKER_HUB_PASSWORD }}"

is caching the image at a version where the most recent version is Dune 3.16. I can add some no-op actions to overwrite the cache but it would be nicer if we just deleted the cached image and let it regenerate a new one. I tested it locally and when you build it you get 3.18.1 (at the time of writing).

So the question is: who has access to ocamldune on Docker Hub?