dev meeting 20210621

Present at the meeting:

• James Somers (@jsomers)
• Carl Eastlund (@ceastlund)
• Guillaume Petiot (@gpetiot)
• Nathan Rebours (@NathanReb)

Current plan

• Nathan helps Jules get the support of MDX labels in mli files in
• Guillaume and Carl work out the ocamlformat RPC protocol together so that the RPC client library can talk to a custom binary
• Guillaume add formatting of raw OCaml blocks to the existing ocamlformat PR

Meeting notes

James recently finished setting up MDX with ocamlformat-ting enabled at Jane Street. It worked well but the two main problems were that:

1. it was using the default profile and there was no simple way to configure it
2. in mli files, the output conflicts with other formatting tools used at Jane Street

Carl confirmed that our suggestion to allow configuring the RPC client library to talk to a different binary than the ocamlformat RPC server would work for them. That would both enable them to set the profile they want and to eventually wrap ocamlformat and the other formatting tools they use together. The advantage of this solution from MDX point of view is that MDX doesn't have to know anything about these bits of configuration or how the RPC client and server speak to each other. We need to work out the detail about who's responsible for starting the server process and through which channels the client will communicate with it. Guillaume and Carl will talk in the next few days to arrange something on that front. The best solution would obviously be to let the build system start those RPC servers and assign them to different MDX processes, via environmnent variables. If we still have to pass the server binaries path for the client to start them it's also completely fine for now. I think the focus is to get something working since according to James' experiments, the performance hit of this approach wasn't really noticeable.

James asked if MDX could also format the so called raw OCaml blocks. Given that those really are just toplevel blocks, with a single phrase and no evaluation outcome, it should be fairly easy to adapt Guillaume's PR to do that.

Jules from the odoc team opened a PR on MDX with the upgrade to the development version of odoc's parser. That will make MDX ready for the next odoc release, where the parser will be split out into a separate package, mostly to avoid circular opam dependencies. It also happens that Jules graciously incorporated the support of MDX labels in mli in that same PR. Indeed, the new odoc parser added support for headers in code block we needed to properly add that feature to MDX. The PR is still draft as the odoc team is working on the details but we should be ready to release MDX whenver odoc 2.0 hits opam, with support for labels in mli files!