A more user-friendly dune

Ecosystem
1

Inspired by the above quote from this thread, I’d like to ask you all…

What would you like to improve in Dune?

Assume I’m willing to spend the time to implement your wish list.

1 Like
2

It’s a bit tangent (more related to dune Cram tests than the Dune “core” itself), but I’d really like Cram tests to have a specific syntax for external oracles. All other solutions (using non-Cram tests, putting the entire oracles in the run.t file, etc) are much less convenient.

Otherwise, concerning Dune tests: showing counts of failing tests, showing counts of tests already cached, and some overall way to make things more “intuitive” for beginners (to help them understand what is being done or not being done, such as “this test has been disabled due to such enabled_if condition not being met”), all could help.

Another minor usability issue for me is that, because Dune targets start with @, I cannot type dune build @<dir>/ and then tab to get some completion based on existing file paths. But this must be easily solvable, I just didn’t take the time to look into it.

1 Like
3

What is the reason for starting Dune targets with @?

4

Support for creating an MLI file for an ML files that doesn’t have one. The created file could be a starting point that gets trimmed down by the developer. Several tools exist to extract an MLI file but they lack integration.

1 Like
6

It is very well supported on the editor side (Merlin and OCaml LSP when you open an empty mli file or using infer-interface command).

1 Like
7

Honestly I don’t really know where to start there is so much you can start working on!

Look in the bug tracker

Thre are lots of open issues. It’s not like many of the issues with dune are unknown. And many are related to usability!

The ones I have opened or interacted with recently:

And something I haven’t opened an issue for yet:
when you have dune in watch mode on the side doing a rather large build, and you use dune rpc to trigger a small job, you only get the result for the small job after the large job is finished, regardless of whether the small job finished before; instead dune rpc should return as soon as the provided target is done building

Look at any part of the doc

The documentation is lacking in many areas.

E.g., the documentaiton on build context simply says that the context stanza defines a build context and we’re supposed to kind of know what it is I guess: context - Dune documentation

E.g., the documentation for the very basic executable stanza says that the libraries field “specifies the library dependencies” and then points to a page with advanced topics, some mention of real names (no link to what that means) and public names (same), a discussion of inter- and intra-project dependencies, and a single example (libraries base re) (is that an example of real-vs-public name??). I don’t think a beginner can really get going on that I think the expectation is they do copy-paste.

I don’t know I think just go through any page and there’s lots to improve.

1 Like
8

Is there a company behind Dune development or is it just volunteers?

9

Dune 3.20 added the -alias and -alias-rec arguments to address this problem

2 Likes
10

In make, phony targets start with a . Turns out that’s not so convenient because we’d like some file targets to also have this prefix. Dune chose a prefix that is less likely to overlap with file targets. Unfortunately, it has its own problems.

4 Likes
11

Happy to see interest in contributing to dune!

A search in dune issues with a filter like this can turn up a lot off feature requests and ideas for improvement: GitHub · Where software is built

There is more open-ended discussion in ocaml/dune · Discussions · GitHub

Our CONTRIBUTING.md has information about getting started as a contributor, and our preferred protocols for contributions. This document also gives a (partial) answer to your question

Dune is an community orientated open source project. It was originally developed at Jane Street and is now maintained by Jane Street and Tarides together with several developers from the OCaml community.

I believe that at least some of the development time the “developers from the OCaml community” have been funded by companies. But I couldn’t tell you for sure which. It is mostly a community effort.

More on the history can be found at Jane Street Blog - How we accidentally built a better build system for OCaml

1 Like
12

What are those existing but unintegrated tools?

13

The man page has zero details about it

$ dune --version              
3.20.2
$ dune build --help
[…]
       --alias=VAL

       --alias-rec=VAL

[…]

Can you explain what it does?

14
1 Like
15

Is there a way to see all the externals libraries declared in the libraries stanza and be sure they all are reported in dune-project? I usually forgot to declare them here when I add a new dependency in a project and only discover the issue after starting a new switch without any package installed.

16
17

I’m taking a stab at this one. Tests are tricky but I may have a PR today.

18

I wish I didn’t have to write dune* files for basic projects. More precisely:

  • I wish dune would assume that a directory a/b/c containing a file named main.ml would assume it contained a dune file containing (executable (name c)). It could also possibly do a dependency analysis to include a (libraries) stanza for internal libraries.

  • I wish dune would assume that a directory a/b/c containing .ml* files but no main.ml would assume it contained a dune file containing (library (name c)). Same deal about the dependency analysis.

  • I wish dune would assume that a directory a/b/c/test containing a file named main.ml would assume it contained a dune file containing (test (name main)). Probably useless without the dependency analysis to also deduce (libraries) though.

  • I wish dune would assume the current directory contained a dune-project file containing (lang dune whatever.version) if it couldn’t find a dune-project file.

I like to start many projects (and never finish them of course), and to do quick experiments in /tmp, and to write quick scripts in OCaml (single .ml files that only depend on Stdlib), and always having to write those dune and dune-project files feels like a chore. Let dune make reasonable default assumptions for me, and let me ask dune to generate the files with those default assumptions for when I want to grow my projects out of their embryo stage.

Another wish I have is for (an option to make) the file system hierarchy to define the library / module hierarchy. File a/b/c/d.ml would define a module accessible from anywhere as A.B.C.D, or from a/b/c/ as D, or from a/b/ as C.D, or from a/ as B.C.D. Ideally without the need to declare the dependencies in dune files of course.

The file hierarchy thing may require some patches to the compiler itself for an efficient implementation (I know because I implemented a build system for OCaml with this feature and I basically had to generate .ml files and insert some code into other files to make it work). It may also not really work with the current state of OCaml dependency analysis because of opens etc. (my build system required you to declare all module-level dependencies manually as (* USES *) comments in source files).

To sum up, I just want to write files like:
/my_stdlib/a.ml
/my_stdlib/b.ml
/my_project1/main.ml
/my_project1/my_sublib/c.ml
/my_project1/my_sublib/d.ml
and be able to run dune exec my_project1.exe without having to write any dune or dune-project file. Kind of like ocamlbuild, if we’re allowed to mention that name in 2025.

Seems to go against the current spirit of dune but you asked for my wishes, so… :slight_smile:

2 Likes
19

The file hierarchy thing may require some patches to the compiler itself for an efficient implementation

Indeed, I wished the compiler would have implemented by default a mapping between modules and directories and used flags to override this. Instead, we now have dune implementing this and it makes it almost impossible to invoke the compiler from the command line because you need endless flags to find all libraries. So working without dune (or something that knows where the libraries are) is almost impossible.

20

I’m not advocating going back to it, or disagreeing that compiler support for this wouldn’t be a brilliant improvement, but dependencies still install in a findlib-compatible way (I think universally with Dune, still - possibly some of the virtual library things don’t map?), so it’s just ocamlfind ocamlopt -package unix,re,etc -linkpkg my_file.ml … at least, it’s only as endless as the list of dependencies?

1 Like
21

Fair enough. Had forgotten why we need ocamlc, ocamlfind, dune and opam :wink: