Switching to Fourmolu 0.14

[Kleidukos]

Now that Fourmolu has integrated the Cabal codebase as a regression test (for which we are very grateful), let's examine what would change if we switched to 0.14: https://github.com/fourmolu/fourmolu/blob/main/compat-tests/cabal.diff

Question 1 (for cabal devs): Is this acceptable to us?

Question 2 (for Fourmolu devs): Are you willing to ask and receive help to provide the next versions of fourmolu with flags to deactivate arbitrary changes from Ormolu?

cc @brandonchinn178

[ffaf1]

I honestly expected a larger diff, good to know it is not so. I find some new formatting rules weird

https://github.com/fourmolu/fourmolu/blob/bf7480982b7e1d77df383277a2a8e788c1082dda/compat-tests/cabal.diff#L375-L380

but it is minor thing and such is life with an automatic formatter.

[chreekat]

I'm not terribly impacted since I hardly qualify as a cabal dev, but I don't really find it acceptable. One whole half of the value proposition of a code formatter is that you don't have to do combat with whitespace changes in the Mines of Git History. 🧙‍♂️ Sure, an automatic formatter changes your code before you commit it, but that's supposed to be so that it doesn't get changed later...

[ffaf1]

you can --ignore-rev, indeed it is a bit cumbersome

[Kleidukos]

you can --ignore-rev, indeed it is a bit cumbersome

We have a file that stores commits to ignore and git does that for us already :)

[chreekat]

Neat! I guess that counteracts my issue?

[ffaf1]

We have a file that stores commits to ignore and git does that for us already :)

Almost. If a PR introduces more reformatting than its scope (happens with e.g. indentation), then it gets squashed+merged, and you have to go back with git annotate to find the right commit.

[ulysses4ever]

I'm sorry I'm not quite following the technical discussion here, but just wanted to add my vote for upgrading to 0.14, as I expect it to be less confusing for newcomers to align with the latest release of the formatter rather than to some past version.

I don't think any new arguments against the upgrade are brought: all the same annoyances applied when we initially did this, and yet we went ahead with it...

On a similar note, I'd also switch the make rules so that phadej's rule is the default. There should be a comment in CONTRIBUTING.md, though, explaining about its assumption: you must run it before committing your changes. And after you commit, you need to resort to the default-today, slower rule. That's my understanding: I may be wrong.

[brandonchinn178]

Almost. If a PR introduces more reformatting than its scope (happens with e.g. indentation), then it gets squashed+merged, and you have to go back with git annotate to find the right commit.

I'm not quite sure what this means. If you run fourmolu once and make a commit, then you can just take that hash and add it to the ignore-revs file. Then merge the PR (dont squash) and itll be good. If you really want to squash, merge the fourmolu change first, then make a separate PR to ignore the rev after committing the formatting change to master.

I find some new formatting rules weird

Perhaps a bit weird at first, but it follows from the fixity rules. With the new fixity rules, Ormolu will actually group the fixities appropriately. In fact, I think it would allow the following, which IMO is much clearer than the current situation:

root
  </> dir
  </> file <.> ext

Are you willing to ask and receive help to provide the next versions of fourmolu with flags to deactivate arbitrary changes from Ormolu?

It would really have to be a case-by-case basis. I'm weakly opposed to flags only existing for the purpose of backwards compatibility. Each flag also adds branches to Fourmolu that makes it harder to resolve conflicts when merging Ormolu.

Ormolu/Fourmolu is not perfect and is still improving, and IMO it'd be a shame to propagate poor formatting just to avoid a one-time change. Perhaps for an especially egregious change, but I'd generally prefer not.

[Kleidukos]

@brandonchinn178 Thank you for your feedback. :) In our situation I think that diffs like the one you have in your repo would be acceptable but the arbitrary changes that we receive from Ormolu can be a little daunting at times. Personally I'm happy that we get to collaborate like this and this fills me with trust.

[Mikolaj]

Great news about the tiny diff. I'm for switching, too.

[andreabedini]

I have no problems with keeping up to date with fourmolu. Expecially if can count on @brandonchinn178's help and advice.
From a contributor POV, it would be great to have some tips&tricks to deal with formatting changes when merging or rebases (i.e. the kind of things @brandonchinn178 wrote just above).

[9999years]

I asked the Cabal maintainers about this a couple weeks ago, and it sounds like they want a Fourmolu release including this commit before they'll upgrade: fourmolu/fourmolu@4e2af8f

I'm happy to do the work of upgrading to a new formatter after that lands (I like having the formatter available, even if it's not perfect).