Support a `--compatible` flag

[sellout]

It can be difficult to get all developers on a single release of Ormolu (e.g., users of VSCode apparently have no idea what version they’re using, and no way to change it).

Instead of forcing developers to be on the same version, support a --compatible flag, so that

ormolu --compatible 0.5.2.0

• fails if ormolu is older than 0.5.2.0
• only applies formatting that won’t “cycle” with 0.5.2.0 or any version afterward.

E.g., I forget which version introduced it, but formatting myFun :: Functor f => f a -> f b as myFun :: (Functor f) => f a -> f b is a backward compatible change, as no version (at least not >=0.5.2.0) will remove the parens from the constraint.

But if 0.5.2.0 coverted (x y) to ( x y ), but then 0.7.0.0 converted ( x y ) to (x y), running ormolu-0.7.0.0 --compatible 0.5.2.0 would’t remove spaces inside parens, to avoid cycles of changes.

This effectively sets a lower bound on the version (and perhaps an upper-bound, as at some point it might be impractical to keep managing things that worked a dozen versions ago, so then you fail saying “0.5.2.0’s format is no longer supported”).

[amesgen]

It can be difficult to get all developers on a single release of Ormolu (e.g., users of VSCode apparently have no idea what version they’re using, and no way to change it).

Not directly related to the workaround you are proposing, but if it is possible to run the HLS executable in VSCode, one can run

haskell-language-server --list-plugins | grep ormolu

to see the Ormolu version.

---

Also, there is the the following HLS config option:

haskell.plugin.ormolu.config.external, default false: Use an external ormolu executable rather than the one packaged with HLS.

This is also available in the VSCode extension. This way, VSCode HLS users can also use the CLI, and it is much easier to control the precise Ormolu version here as you point out.

Just mentioning this in case this works for your use case, as it seems much simpler a priori compared to implementing this ticket and/or #1127. Let me know if that works for you!

[aryairani]

Not directly related to the workaround you are proposing, but if it is possible to run the HLS executable in VSCode, one can run

haskell-language-server --list-plugins | grep ormolu

to see the Ormolu version.

Thanks, but I'm not actually able to see the version, just the word ormolu; none of the plugins are listed with their versions:

% haskell-language-server --list-plugins | grep ormolu
ormolu

% haskell-language-server --version
haskell-language-server version: 2.4.0.0 (GHC: 9.2.8) (PATH: /nix/store/j0v7rf27azv0m0d5q7fq66nfgijjll8r-haskell-language-server-exe-haskell-language-server-2.4.0.0/bin/haskell-language-server)

[amesgen]

Thanks, but I'm not actually able to see the version, just the word ormolu; none of the plugins are listed with their versions:

% haskell-language-server --list-plugins | grep ormolu
ormolu

% haskell-language-server --version
haskell-language-server version: 2.4.0.0 (GHC: 9.2.8) (PATH: /nix/store/j0v7rf27azv0m0d5q7fq66nfgijjll8r-haskell-language-server-exe-haskell-language-server-2.4.0.0/bin/haskell-language-server)

Ah, this seems to be a new-ish feature of HLS, it works starting with HLS 2.6: https://github.com/haskell/haskell-language-server/pull/3903

FTR, I am seeing this with a local HLS 2.7:

 $ haskell-language-server --list-plugins | grep ormolu
ormolu:
    Provides formatting of Haskell files via ormolu. Built with ormolu-0.7.4.0

[sellout]

@amesgen Thanks! Part of the issue is definitely that I don’t use VSCode myself, so it’s hard to help diagnose things. And then there are outside contributors who might not configure things the same way as employees, etc. hls --list-plugins is a great tip, though.

I find that haskell.plugin.ormolu.config.external isn’t ideal as it just runs whatever’s on the PATH (or whatever that is on the appropriate platform) rather than letting one specify the executable to use. If a user has an HLS configured with the correct Ormolu, then setting haskell.serverExecutablePath directly to the path of that HLS seems like it’d work (we do provide a Nix environment that has a correctly-configured HLS+Ormolu, if the user is so inclined).

Not an Ormolu problem, but it’s slighly unfortunate that the VSCode plugin doesn’t allow for direct configuration of Ormolu (I don’t think). It just gets whichever one is used for building the HLS that is selected, at the time that the plugin is first activated. So VSCode users seem likely to end up with varied versions.

I haven’t found anything in the docs, but it’d be helpful if there was some guidance in general on how to get consistent formatting across large/fluctuating sets of contributors. E.g.,

• auto-format in CI so that contributors don’t have to think about it (we seem to have an issue where GH doesn’t re-run checks after the formatting, so it’s possible to overlook an earlier failure, or to not run required checks after an auto-format commit)
• how to provide a consistent environment for contributors who do run it locally (like the Nix environment I mentioned and we also make our recommended (and pinned in Nix) versions of everything pretty discoverable – stack, hpack, hls, …). Maybe there’s something that can be put in .vscode/settings.json to help pin the version more directly?
• this ticket’s --compatible flag could also help
• etc.

And finally, just thanks for Ormolu – if nothing else it has largely killed the leading-comma abomination 😆

[aryairani]

Ah, this seems to be a new-ish feature of HLS, it works starting with HLS 2.6: haskell/haskell-language-server#3903

Ah, yeah. I just discovered and came back to share the same thing, about HLS 2.6+

I see also that since HLS 2.1, you can see the ormolu version in the HLS log output, if the log level is set to debug; so that solves my problem. Sorry for polluting this thread about it.

[michaelpj]

Relevant: https://github.com/haskell/haskell-language-server/issues/411