Update APE20 for Black formatting not just the Black tool

[taldcroft]

Since APE-20 was accepted in 2022, another auto-formatting tool has become available that also implements the default Black format and has gained popularity. This development highlights that APE-20 was written with a somewhat short-sighted perspective -- it focuses on using the Black tool instead of adopting Black formatting using whatever Black-compatible auto-formatter is appropriate.

Changing the entire PR to reflect this change is not that helpful, but instead this PR adds a few words in the abstract to reflect this broader perspective. Adoption of this PR is technically a lien on changing the astropy Black-format CI check to another tool.

[pllim]

Thanks! I will put this on agenda for dev telecon.

xref https://github.com/astropy/astropy/issues/15757

[pllim]

So far no one objects, so I added this to CoCo agenda for 2024-01-22 when we next meet. Thanks for your patience!

[astrofrog]

If uncontroversial this could be put to the full voting members list for a vote instead of waiting for the coordination meeting which might only have a fraction of voting members.

[dhomeier]

Fully agree with making this tool-independent. Perhaps the heading should also be changed?

Formatting Code in Black Style

And since the modified text now becomes a little bit more specific about what is the Black code style, it would be good to note that its exact incarnation to be followed is decided per case, sort of. In particular since Ruff has some history of pulling in whatever formatting or linting rules can be found as (optionally) available ruleset, I am wondering if its "standard" format will always stay in sync with Black itself (but even when we first adopted it, I think Black itself had somewhat different rulesets in stable and developer versions).

[pllim]

put to the full voting members list for a vote

I guess https://github.com/astropy/astropy-APEs/blob/main/APE0.rst#responsibilities-and-rights does not rule that possibility out, but isn't that slower? Someone has to set up the heliovotebot (or whatever it is called) and then go through the 2 weeks voting period, get the tallies, and so on?

[neutrinoceros]

@dhomeier

I am wondering if its "standard" format will always stay in sync with Black itself

It may be too soon to tell for sure, but their documented philosophy feels like they want/have to maintain black-compatibility long term (else, they would make migration much less convenient, which would kill most of their argument). It's also worth noting that black and ruff contributors have been working hand in hand for a little while (or at least seem to be talking very regularly).

[astrofrog]

I guess https://github.com/astropy/astropy-APEs/blob/main/APE0.rst#responsibilities-and-rights does not rule that possibility out, but isn't that slower? Someone has to set up the heliovotebot (or whatever it is called) and then go through the 2 weeks voting period, get the tallies, and so on?

Yeah sorry I misremembered the process and this is indeed overkill. But maybe we can even reach a consensus before the coordination meeting.

[mhvk]

This really seems super uncontroversial - the APE really was about settling on a specific style, with surely the tool an implementation detail. I'd consensus has already become clear!

[taldcroft]

From what I can see this has been uncontroversial and there is consensus. Jan 22 will be here before we know it, time flies! Is there a PR ready or in-work for migrating to ruff format in astropy?

[neutrinoceros]

There isn't. Can I volunteer ?

Edit: just remembered that @eerovaher had some plans for how to do it. I don't want to step on his toes, but I'm here to help !

[eerovaher]

My plan (that I mentioned at a developer telecon a couple of months ago) was to have a look at the lines in astropy that Ruff formatter would edit and to see if they could be rewritten so that both Black and Ruff formatter would be happy with them. The goal was to reduce the size of the patch that would be required to switch from Black to Ruff formatter, but also to try to improve odd-looking code if possible.

The part of the transitioning that requires the most effort to implement and to review is updating the developer documentation, and my plan has nothing to do with that.

[neutrinoceros]

Ok, then I can do it, as I think I should read that doc anyway ! (I'll still wait for the present update to go in)

[ceb8]

I also approve.

[eteq]

The CoCo today unanimously approved this, will merge shortly!

[eteq]

Hmm, I think someone else might own the Zenodo entry, so it has not been updated yet. Trying to track down who it is...

[pllim]

Oh no... maybe it was me. 😅

[pllim]

OK never heard back from Erik, so if it is indeed under my own Zenodo account, I am just going to update that same record. I don't have time to mess around with this stuff.

https://github.com/astropy/astropy-APEs/commit/ac97aeaf795db5d08f9276d722e13ad2154652a0