Discussing this here https://discord.com/channels/458662222697070613/1335655131500249230/1335655140421800007

Yes? No? Maybe?

Probably. No resistance doing this change but properly mapping out the differences and double checking the config options is a good idea. Also need to make sure the tooling is up to date for the environments people are currently using.

Resolved a conflict with dev branch to keep this up to date.

There's infos on ruff format here: https://docs.astral.sh/ruff/formatter/

Basically it's 99.9% compatible with Black:

As such, the formatter is designed as a drop-in replacement for Black, but with an excessive focus on performance and direct integration with Ruff. Given Black's popularity within the Python ecosystem, targeting Black compatibility ensures that formatter adoption is minimally disruptive for the vast majority of projects.

The 0.1% deviations are explained here: https://docs.astral.sh/ruff/formatter/black/

I think you're already running ruff format and not black currently on precommit:

So this PR would align devdocs / CI in line and go all-in on ruff format vs the current solution of using two formatters and be faster. I think that's the main/only advantage, I would be surprised if anyone cares about the tiny formatting differences between the two.

Let me know if there's anything else I can do here.

Yup. We seems to have the majority of the maintains on board. I will adapt one of my local projects quickly first before I merging this just to get the full picture even if it's meant to be a drop-in replacement.

Will merge in the next few days.

The pre-commit I think was only a test that @eruvanos was using. It had some challenges depending on how your environment is set up. We should probably look into that as well soon.

I'm up for merging this.

1. You fixed some weird fstring issues
2. The root cause for them still isn't fixed in black Combine f-strings which would be placed on the same line psf/black#4389

#2569 just got hit with the exact issue I mentioned (f-string handling in psf/black#4389).

I will adapt one of my local projects quickly first before I merging this just to get the full picture even if it's meant to be a drop-in replacement.

@einarf any reasons not to merge this?

#2569 just got hit with the exact issue I mentioned (f-string handling in psf/black#4389).

I will adapt one of my local projects quickly first before I merging this just to get the full picture even if it's meant to be a drop-in replacement.

@einarf any reasons not to merge this?

Be free to merge. I have been swamped with work.