What about using TOML instead of sexps?
Here is the entry in the manual: Aliases - Dune documentation
Rudi mentioned some of the design decisions behind @. Some problems that --alias = @@ and alias-rec = @ intended to fix were the ability to tap into tab completion and support on Windows cmd. In Windows for example, @ means something else, but is fine on more modern powershell terminals.
The manpages are however missing documention, I’ve opened an issue here about that. doc: document --alias-rec and --alias in manpages · Issue #12722 · ocaml/dune · GitHub. I’ll add it later today if nobody picks it up.
I would consider cram tests part of “core dune”. We are definitely interested in the UX and have done some work recently in that direction with timeouts Cram - Dune documentation and soon-to-be-released conflict marker detection.
I have experiemented with implementing failing test counts, but all my experiments have required modifying the core parts of the engine in various ways which I never felt was the right solution. It’s worth noting that the long-standing issue of re-playable warnings: warning 9 enabled by default in dev mode · Issue #8645 · ocaml/dune · GitHub is related. We need a way to display some information to the user that isn’t an error and can be replayed from cache hits.
Regarding the enabled_if condition, that’s something we have discuss adding detection for in dune runtest. The idea would be if you specifically ran a disabled cram/inline/executable test then dune runtest would spit out a warning with the disabled stanza location and reason.
I’ve created an issue for it here so it can be tracked: dune runtest should warn about `enabled_if` · Issue #12723 · ocaml/dune · GitHub
If you are building specific aliases, as mentioned we have new --alias-rec name and --alias name arguments that are equivalent to writing @name and @@name respectively. Further documetnation can be found in Aliases - Dune documentation.
If you are running (cram) tests, then it might be better to instead use the dune runtest path/to/cram-test.t instead since you can tap into the shell completion and expansion.
It’s not clear to me what the best way to expose this to the user via dune would be. I suggest we open an issue for this feature request. It would be helpful if you could describe what your “wish” might look like on the cli.
I think it would be more useful if we could detect the externally used values, types, modules, and functions, and only add those to the mli. That seems a lot harder to support and probably needs to start as a feature in merlin.
the online manual is insufficient in this case, there is no documentation for the CLI arguments.
I’ve commented on your GH issue with more specific questions
I’m happy to open a feature request. Maybe there is already a way to do this from the command line. If we use ocaml -i the problem is to pass options to find all the required libraries. I believe the typical use case is to infer the MLI file for a specific file rather than for every ML that has no MLI file. This is why I think it this needs to be a dune command/option.
There was a discussion about doing setting up .inferred.mli rules for every module. Unfortunately, this requires adding a new rule for every single module which has a non trivial overhead. As pointed out earlier, this is already well covered by merlin/ocaml-lsp, so it doesn’t seem like paying this performance cost to do the same thing in dune is worth it.
Should be solved by Dune: Concurrent builds are here! - #3 by joelreymont