dune format-dune-file doesn't respect the formatting stanza

[Khady]

In a project with a dune-project that says (formatting (enabled_for ocaml reason)), running dune format-dune-file will still format the dune file despite the formatting stanza saying that it shouldn't happen.

The problem mostly appears when using ocamllsp as dune format-dune-file is a low level command that one usually doesn't call directly.

dune 2.5

/cc @rgrinberg @emillon

My understanding is that dune format-dune-file is indeed a low-level command that doesn't read the dune-project file. Though it seems like it should given that the formatting of dune files is versioned as per this discussion.

[rgrinberg]

Yeah, it’s indeed intended to be a low level command. The problem is that we don’t have a suitable high level way to format dune files. I suppose this could be added as a use case in the RPC issue

…

On Jun 1, 2020, 2:17 AM -0700, Jérémie Dimino ***@***.***>, wrote: /cc @rgrinberg @emillon My understanding is that dune format-dune-file is indeed a low-level command that doesn't read the dune-project file. Though it seems like it should given that the formatting of dune files is versioned as per this discussion. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

If we start doing the formatting in-process, do we still need dune format-dune-file to be low-level?

[emillon]

To confirm, yes, dune format-dune-file is supposed to be a low level command and always format its input. A high level frontend to @fmt to check (or fix) formatting of all (or some) files based on the dune-project configuration would probably be enough to fix this problem.

We should probably compare what dune does to what ocamlformat does. My understand is that right now, the editor calls ocamlformat <file> and this command will read the ocamlformat configuration files to decide whether and how to format the file. Is that correct?

[jberdine]

My understand is that right now, the editor calls ocamlformat <file> and this command will read the ocamlformat configuration files to decide whether and how to format the file. Is that correct?

Yes, with the caveat that (at least the emacs integration) dumps the possibly-unsaved contents of the editing buffer to a temporary file and passes ocamlformat a -name flag to tell it where to look for configuration files.

Do we think this mode of operation is the right one? From a distance, it seems good to me.

If we think it is, then we should add a similar feature in Dune. i.e. add a dune command to format a dune file taking into account the dune configuration files, and taking a similar -name flag.

For formatting dune files as part of the build, we decided that it's ok to do the formatting in-process, so we shouldn't really need the low-level command anymore.

[nojb]

For formatting dune files as part of the build, we decided that it's ok to do the formatting in-process, so we shouldn't really need the low-level command anymore.

See #3536

[Leonidas-from-XIV]

I ran into a case where I wanted to reformat dune files even if it wasn't enabled in the project (due to programmatic editing of dune files with tools like sexplib and then cleaning up the processed output by reformatting). In this case dune format-dune-file reformatting always enabled independently of the project settings is quite helpful.