Update JuliaFormatter to v2

[lkdvos]

This updates the version of the formatter to the latest version. There are a bunch of changes here that I don't really like, but it is definitely annoying to have to keep switching formatter versions between different packages so I don't think there is anything better to do about that.

[codecov]

Codecov Report

Attention: Patch coverage is 96.15385% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/states/quasiparticle_state.jl	50.00%	1 Missing ⚠️

Files with missing lines	Coverage Δ
src/algorithms/approximate/fvomps.jl	95.65% <100.00%> (ø)
src/algorithms/approximate/idmrg.jl	95.69% <100.00%> (ø)
src/algorithms/changebonds/optimalexpand.jl	100.00% <100.00%> (ø)
src/algorithms/changebonds/randexpand.jl	100.00% <100.00%> (ø)
src/algorithms/changebonds/svdcut.jl	92.85% <100.00%> (ø)
src/algorithms/excitation/chepigaansatz.jl	91.48% <100.00%> (ø)
src/algorithms/groundstate/dmrg.jl	100.00% <100.00%> (ø)
src/algorithms/groundstate/gradient_grassmann.jl	75.00% <ø> (ø)
src/algorithms/groundstate/idmrg.jl	98.38% <100.00%> (ø)
src/algorithms/statmech/idmrg.jl	97.72% <100.00%> (-0.76%)	⬇️
... and 5 more

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[VictorVanthilt]

This is horrible

[lkdvos]

This is precisely why I haven't don't it yet...

[VictorVanthilt]

Thank you <3

[VictorVanthilt]

The JuliaFormatter team really did a number on their code and my formatting has never been happy since

[Jutho]

Any experience with trying Runic.jl instead of JuliaFormatter? I also don't like many of the formatting changes induced by v2.

[lkdvos]

I have been trying it and while I quite like it, it’s a bit more involved to set up, and it’s annoying to switch back and forth. If we switch the entire quantumkithub I’m also okay with that

[Jutho]

I haven't tried it yet; does it cooperate as easily with VS Code (i.e. does it support "format on save"?). If so, then I wouldn't mind switching.

[lkdvos]

It's not too hard to install in VScode but it's slightly more work than the usual setup. The instructions are on the Runic readme so it should be fine.

[lkdvos]

For comparison: #303

[Jutho]

For comparison: #303

So what do you like the most? I think I like certain aspects of Runic, such as spaces around = (even in keyword arguments) and after commas (even in parameter lists), although I have gotten used to not having these spaces as imposed by the current formatting style.

I do have to get used to the way Runic divides arguments of functions (calls or definitions) across multiple lines.

[VictorVanthilt]

I agree with Jutho here, there are some aspects of Runic that seem unnatural to me. I do like the fact that the rules are "set in stone" (unless a v2 is released) and splitting up overly long list comprehensions is a nice addition. The installation process is a bit more involved than JuliaFormatter, making the barrier for some less technologically inclined people to contribute to the codebase a bit higher, getting people to format their code now is sometimes already a hassle :)

[lkdvos]

I think the JuliaFormatter v2 things that stand out are a lot uglier than the ones from Runic, and I have to admit that while I originally also wasn't convinced about how the arguments split, it doesn't bother me as much now.
Important to note here is that actually Runic doesn't really impose that much with respect to these argument lists, the only thing it does is that it adds indentation such that the arguments come at a different indentation than the first line of the function. How you split them across lines is totally up to us, and Runic does not actually impose a line length limit either.
All things considered I like the Runic style the most (read: it has the least things I dislike), so for myself this is what I would pick.

However, as @VictorVanthilt mentioned, most people don't have this set up, so it does increase the barrier for contributing. This is typically not a major problem, and could even be resolved with github actions, but it is definitely something to consider.

I think the main issue is that it is very subjective and I don't think it matters all that much, as long as it is consistent. Having something that is easy might outweigh having something that looks nice, unless we all (more or less unanimously) agree that Runic looks better, in which case I'll try and set up some tooling to make this work.

[lkdvos]

@pbrehmer , @Yue-Zhengyuan , @leburgel , @sanderdemeyer , I'm explicitly tagging all of you here in case you would like to share your opinions, since I would prefer to keep everything consistent across QuantumKitHub to also minimize the amount of tooling we have to maintain.

[sanderdemeyer]

I have a slight preference for keeping JuliaFormatter w.r.t. Runic for the reasons mentioned by Lukas and Victor. As for the version, I would be okay with either one (although I have a very slight preference for keeping v1 for now). The most important thing in my opinion is indeed, Like Lukas said, that we come to a conclusion here that we stick to throughout the whole QuantumKithub.

[pbrehmer]

Based on my first impressions I like the Runic style most since I find it very readable. I definitely appreciate the spaces around = and in type parameter lists and in fact I like the way the function arguments are indented and split up in #303.

I agree that the technical hurdle Runic introduces is not ideal and I do find it slightly annoying that it is the non-standard option (since code formatting should really be standardized IMO and already be shipped with the language like with Rust for example). I also agree with Lukas that this problem could be taken care of with Github actions.

Personally, I would slightly favor Runic. Overall though, I have to say that I don't have a strong opinion and would also be fine with using JuliaFormatter (v1 or v2) as long as it is used consistently.

[Yue-Zhengyuan]

I prefer JuliaFormatter (with blue style). Coming from Python, I dislike anything that doesn't use 4-space indentation. I don't know why in #100 blue was ditched in favor of yas, but from my perspective the yas style is really an abomination (particularly how it indent arguments of a function with a long name).

It's also OK if we finally decide to use the Runic style; it's not ideal, but much more tolerable for me.

[lkdvos]

I agree with that sentiment, unfortunately blue is rather incompatible with the @tensor macro, as it formats our indexnotation into arrays, and in particular it removes the ;. The example is a bit contrived to make it work with enough indentation to hit the linewidth, but in MPSKit we have a couple very nested contractions:

# yas:
begin
    begin
        begin
            begin
                begin
                    begin
                        @tensor A[i j; k l] := longerasdfasdfasfasdftensorname123asdfasdfasdfasdfasdfasdf[i j;
                                                                                                          k l] *
                                               longtensoasdfasdfasdfasdfasdfrname2[i j k l m n o;
                                                                                   p q r s t o v]
                    end
                end
            end
        end
    end
end

begin # blue
    begin
        begin
            begin
                begin
                    begin
                        @tensor A[i j; k l] :=
                            longerasdfasdfasfasdftensorname123asdfasdfasdfasdfasdfasdf[
                                i j
                                k l
                            ] * longtensoasdfasdfasdfasdfasdfrname2[
                                i j k l m n o
                                p q r s t o v
                            ]
                    end
                end
            end
        end
    end
end

---

So summarizing the sentiments:

1. In general most people have a slight preference for runic style-wise, with one vote for blue, and one vote for yas with JuliaFormatter v1
2. I think I would vote against blue for the reason described above
3. I think sticking with JuliaFormatter v1 in the long run is as inconvenient as switching to Runic, since most people will start using v2 and it is even less trivial to switch the autoformatter in VSCode between different versions of JuliaFormatter.

So for me this boils down to either switching to Runic, or sticking with JuliaFormatter v2.
Would everyone agree with switching to Runic then?