Document corresponding versions for standalone tools (e.g., fourmolu) for binary releases

[tgiannak]

Is your feature request related to a problem? Please describe.

I use fourmolu both via the language server and as a standalone tool in my CI process. When the versions differ, sometimes the behavior does too, which results in the CI checks failing even though everything looks OK according to the language server. This was especially surprising with today's 1.6.0.0 release, which I had expected would be built against fourmolu 0.5.0.1. (Whatever version is included in the language server differs in its behavior with respect to Haddock comments with comma-style: leading.)

Describe the solution you'd like

Document which versions of the standalone tools correspond to the plugins in the released haskell-language-server binaries, so that I can pin my standalone tool installs to those versions.

Describe alternatives you've considered

I can't just go by the bounds listed in the cabal file for the plugin because they admit multiple major versions. The versions listed in the various nix files differ, so I can't go by those either.

[michaelpj]

Related #411

[michaelpj]

Here's how I work around this problem: build HLS from source with extra constraints pinning the formatter version to the one that you want. (It might not work, but then at least you know you need to e.g. upgrade the one you use in CI). That way you can ensure that the version you use outside HLS matches the one used by HLS.

[tgiannak]

I would gladly do that it it were just for myself, but I have a team of Haskell novices that I need to support as well. Matching our CI version to whatever is already distributed via ghcup would be easier than getting them all to build it themselves.

This process of producing the documentation could also be useful internally for figuring out which plugins were keeping which other plugins from being built against their newest versions due to bounds on common dependencies. Trying your suggestion, it looks like (at least) stylish-haskell and fourmolu ^>= 0.5 have conflicting bounds.

[tgiannak]

Here's how I work around this problem: build HLS from source with extra constraints pinning the formatter version to the one that you want.

This was easier than it sounded: a cabal.project file with just the constraints and flags in an otherwise empty directory does the trick for constraining cabal install haskell-language-server installing from Hackage.

[jneira]

Here's how I work around this problem: build HLS from source with extra constraints pinning the formatter version to the one that you want.

This was easier than it sounded: a cabal.project file with just the constraints and flags in an otherwise empty directory does the trick for constraining cabal install haskell-language-server installing from Hackage.

nice, i think you could even take ride of the cabal.project with cabal install haskell-language-server --constraint="fourmolu==X.Y.Z" --flags="+myflag"

[georgefst]

Agreed that documenting the versions seems like a good idea.

As for the specific problem here, as maintainer of the Fourmolu plugin, I've known this was coming for a while: #2254 (comment). Sorry that you've hit it. We need stylish-haskell to update to ghc-lib-parser-9.2 (EDIT: and Cabal 3.6, but there's no breakage there: haskell/stylish-haskell#375) before we can drop support for older versions of Fourmolu. Fortunately @jaspervdj is working on it: haskell/stylish-haskell#378 (comment). With HLS on GHC 9.2, stylish-haskell is disabled, so we do get Fourmolu 0.5.

[georgefst]

nice, i think you could even take ride of the cabal.project with cabal install haskell-language-server --constraint="fourmolu==X.Y.Z" --flags="+myflag"

Exact command is:

cabal install haskell-language-server -w ghc-8.10 --constraint='fourmolu >= 0.5' --flag='-stylishHaskell' --allow-newer=stylish-haskell:*

(--allow-newer still needed to remove stylish-haskell line from cabal.project due to a known cabal issue about not treating local packages as optional)