[ANN] Dune 3.24

Ecosystem
, ,
1

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

Highlights include the following:

  • Dune package management now uses the relocatable compiler by default, for all supported compiler versions. This brings a massive speedup to workspace setup in the many cases where built compiler versions can be reused. (ocaml/dune#14357, @Alizter)

  • Directory targets are now generally available (ocaml/dune#14579), allowing tools to produce entire directory trees as targets. See the documentation on directory targets for details.

  • Path handling has been refined, improving the consistency of paths across platforms (ocaml/dune#14278 and ocaml/dune#14278) and using a more consistent and disciplined location for %{bin:NAME} variable expansions (ocaml/dune#14432).

  • Path-valued percent forms (%{bin:...}, %{dep:...}, %{path:...}, and friends) now expand same-directory paths with a leading ./, so that shells like bash in (bash ...) and (system ...) actions execute them directly instead of looking them up in PATH (ocaml/dune#15156). This is a breaking change for configurations that were handling paths naively, and neglected to normalize the representation before using it test fixtures or for constructing other strings.

  • The deprecated lang coq has been removed, as scheduled, superseded by lang rocq. See ocaml/dune#12788 for details.

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

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

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.

3

@Stephane_Glondu reported that this breaks atd’s tests (see the link to the Debian bug report) because dune passes the file ./test.atd to our command instead of test.atd and the input file path is part of the command’s expected output.

Here’s what I believe is desirable: if a user passes a certain path to our command such as ./foo, we should echo this path in error messages (File "./foo": ..., not File "foo": ...) so that the user can recognize it. That’s why I don’t think we should try to normalize paths from the command line.

As a workaround, our specific project could add a special flag --normalize-paths to remove any leading ./ from input paths. This flag would be used in dune files so that our tests pass without trouble with Dune 3.24. At some point in the future, we’ll require dune >= 3.24 and --normalize-paths won’t be needed anymore. This is pretty annoying, though. Does anyone have a better suggestion?

4

In my project, we already had a test executable that wrapped calls to our actual binary (to make some calling easier and to log exit codes in our own not-quite-cram-style expectation tests), and to account for this breaking change we updated that executable to normalize the paths, so the same output would be seen in both versions without having to change our actual project’s implementation

5

Hi! It’s reasonable that you may not want atd to normalize paths in its execution logic. If that is the, case, I propose addressing this by controlling/normalizing the paths in the test logic. E.g., in

rather than using the path representation dune provides via the %{atd} variable, you can pass in test_annot_error.atd directly, giving you full control over the path input representation. I.e.,

(deps    (:atd test_annot_error.atd) %{bin:atdgen})`
(action`
  (with-stderr-to test_annot_error.stderr`
  (with-stdout-to test_annot_error.stdout`
    (bash "%{bin:atdgen} -t test_annot_error.atd || echo 'Failed succesfully!'")))))`

(The general principle being that data which has multiple valid representations should have its representation normalized – and if necessary masked – before using the representation in a test fixture.)

Does this make sense?

6

I think this will work. Thanks!

7

Maybe we can normalize relative paths in the error messages produced by dune to remove the leading ./? Not sure how helpful it would be, but it would at least make the error messages a little more pleasing to the eye.

8

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

See the full changelog for the new 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.