[ANN] Dune 3.23

Ecosystem
, ,
1

The Dune team is pleased to announce the release of dune 3.23.0.

Along with many other fixes and improvements, some highlights include:

  • Add support for c_library_flags in foreign_stubs (#13484, @madroach)
  • Many improvements to the promotion and diffing functionality, by @rgrinberg.
  • As part of the previous, a breaking change to the promotion logic has been
    introduced: Dune does automatically promote generated opam files, which must
    now be manually promoted with dune promote. You can trigger building .opam
    files with the @install, @runtest, and @opam aliases. In release mode,
    .opam files aren’t generated at all and whatever is in the source is used
    (ocaml/dune#14108, @rgrinberg).
  • User rules and inline test runners are now sandboxed by default
    (ocaml/dune#13805 and ocaml/dune#14257, @rgrinberg).
  • The minimum OCaml version required to build dune is now 4.14.

See the full changelog for all new features and fixes, and for attribution to the contributors
who made it all possible. Thank you, contributors!

If you encounter a problem with this release, please report it in our issue
tracker.

2

This is really annoying. Any chance of it being considered for a revert to fit with the rest of opam-repository instead?

3

Sorry for the annoyance, that was not intended. I’m connecting with other dune devs to work out the options and needs here. We’ll report back tomorrow.

4

Hello! Reporting back :slight_smile:!

First, I want to note that, IMO, we should have coordinated on the plans for this change with concerned parties before moving forward with the change – it shouldn’t have come as surprise. I’ll put this on the agenda for our next dev meeting to see if can ensure this is coordinated better in the future.

I think we should also make sure we are addressing the problem you’re raising! IIUC, the annoyance comes from the fact that some packages in the opam repository will have an upper bound on versions of OCaml < 14.0 and they have no upper bound on their dune dependency, and want to continue using the latest version of dune. Is that correct?

Insofar as this is the concern, I’ve tried to gauge the scope of the impact. This is an imperfect method, but it seems to indicate that only a handful of packages are in this situation:

[17:41:41 ~/Repos/ocaml/opam-repository]
$ rg '"ocaml".*<.*"4.14.0"' -l | xargs rg '"dune".*[^<]' -l
packages/owl-zoo/owl-zoo.1.0.1/opam
packages/owl-zoo/owl-zoo.0.7.1/opam
packages/binaryen/binaryen.0.16.0/opam
packages/owl-zoo/owl-zoo.0.7.0/opam
packages/ppx_tools/ppx_tools.6.4/opam
packages/lutils/lutils.1.54.1/opam
packages/owl-zoo/owl-zoo.0.8.0/opam
packages/camelot/camelot.2.0.1/opam
packages/owl-zoo/owl-zoo.1.0.0/opam
packages/owl-zoo/owl-zoo.0.4.0/opam
packages/ppx_cstubs/ppx_cstubs.0.6.1.2/opam
packages/owl-zoo/owl-zoo.0.7.2/opam
packages/ppx_cstubs/ppx_cstubs.0.5.0.2/opam
packages/owl-zoo/owl-zoo.0.10.0/opam
packages/owl-zoo/owl-zoo.0.9.0/opam
packages/p5scm/p5scm.0.1.0/opam
packages/owl-zoo/owl-zoo.0.5.0/opam
packages/owl-zoo/owl-zoo.1.0.2/opam
packages/binaryen/binaryen.0.17.0/opam
↳[0]

[17:41:50 ~/Repos/ocaml/opam-repository]
$ rg '"ocaml".*<.*"4.14.0"' -l | xargs rg '"dune".*[^<]' -l | wc -l
19

Please let us know if there is a wider concern or I am misunderstanding the problem you anticipate.

The motive for this change is to reduce the dune maintenance burden. But I think it is safe to say that we also want to support as much flexibility as we can and to continue contributing to the culture of strong backward compatibility and long term stability.

To this end, @Alizter has proposed the following change for inclusion in a 3.23.1 patch release: fix: support building dune with ocamlfind-secondary on older OCaml switches by Alizter · Pull Request #14443 · ocaml/dune · GitHub . This should allow packages that require an older version of the OCaml compiler to continue depending on the latest versions of dune, by falling back to the secondary compiler at 4.14 to build dune when needed.

This can be tested in a switch using an ocaml version older than 4.14 with

opam pin dune.dev git@github.com:Alizter/dune.git#push-rwztynqnpuro

We would be keen to get your view on whether this is a suitable solution or if you foresee other problems!

(Incidentally, I was not able to test this on the first two systems I tried, because they cannot install OCaml versions older than 4.14 due to lack of support for recent gcc toolchains :)).

5

The Dune team is pleased to announce the release of dune 3.23.1.

This is a patch release consisting of the following bug fixes.

If you encounter a problem with this release, please report it in our issue
tracker.

Fixed

  • Fix the menhir opam dependency injection introduced in 3.23. Dune now only fills in the lower bound {>= "20180523"} on an existing user-declared menhir dependency; it no longer adds menhir as a new dependency to packages that did not declare it themselves. (#14434, fixes #14428, @robinbb)
  • Gate the dune version-bound deduplication in generated opam files (introduced in 3.23) on (lang dune 3.23). Projects at earlier lang versions get the prior And [...] shape — e.g.
    {>= "3.17" & >= "3.20"} — restoring 3.22 behaviour and avoiding a silent change to opam output on dune-binary upgrade. (#14436, @robinbb)
  • Preserve library order when building a shared jsoo standalone runtime. (#14438, @vouillon)
  • Fix the fallback to the secondary compiler, allowing recovering of support for packages with upper bounds on OCaml less than 4.14. Packages depending on dune 3.23.1 or later and with an upper bound on the OCaml compiler that is less than 4.14, will now be able to use the latest dune, but dune will be built with the secondary compiler at version 4.14. (#14443, @Alizter)
  • Fix the bootstrap on NetBSD by including <sys/wait.h> in lev_stubs.c, matching the existing FreeBSD/OpenBSD guard. (#14512, fixes #14484, @0-wiz-0)