[maratc]

> These tools don’t add extra commits.

When you replace tool x with tool y, you need to fix your code, because these tools do not agree on what your code should look like, and what was acceptable for tool x simply isn't for tool y.

One of these changes I mentioned brought a massive reformatting of all code base, as the new tool failed 'import' statements unless they were in alphabetical order.

[OoooooooO]

If you change the formatter for your project then yes, you have a single commit where you reformat your project and then commit this.

A single commit after a tool change. I don't see the problem.

[MawKKe]

Sounds like the issue is not the tools themselves, but that the project management / stewardship allows someone to replace tools willy-nilly leaving others to pay the cost of migration?

At $WORK we have "code guardians" whose responsibility is do to this kind of migrations strategically in the background. The intent is that most other developers should not need to do any (or very little) extra work beyond the task they are actively working on.

[maratc]

The linked article says that ruff now has 413 default rules -- instead of 59 previously. Do I understand it right that all the projects that were using ruff were 100% conformant to 59 rules yesterday but likely not conformant to 413 rules today, which will cause breakage all across the board? Likely immediately followed by a swarm of pull requests all formatting their code in conformance to whatever these new (413-59) rules are?

There's no "tool replacement" going on here.

[MawKKe]

Well, that's the danger of using software without version pinning.

Also, usually tools like Ruff can be configured to enable/disable project-specific formatting rules (via a config file), allowing you to suppress the defaults you disagree with, or whose consequence you don't want to deal with _right now_. Some tools might even support suppressing specific rules per-file, so you can migrate codebase over time instead of in one go.

Having a config that explicitly defines the rules enforced in the project is really useful, and perhaps even crucial the bigger the project grows.

[maratc]

The options you suggest seem to be either (a) feed the bot now (halt development and reformat all code) or (b) under-pin/suppress and feed the bot later, probably dealing with people adding more non-conformant code to already-reformatted files.

You will probably have to do it all over again when these guys release even newer and shinier 0.17.0, with even more rules.

I can't understand how the option of not feeding the bot eludes people.