Those tools actually save team energy. Without them any programmer has different opinion on formating, code quality, what is readable etc. You can discuss it endlesly or you can just use ruff.
Another option would be to leave both topics alone and go on with our lives, improving the product, fixing bugs, implementing new features, and generally giving customers a better product and shareholders more value, while respectfully agreeing to disagree on the issues of style.
First, my other dependencies usually deliver something of value to the customer (and so I deliver my other dependencies to the end-user installation.) Second, when I need to change code to accommodate other dependencies, it is usually limited to a couple of files, sometimes to a couple of modules; this change will touch much, much more than that. Third, my other dependencies at least play nice by implementing semver and bumping a major release on a breaking change.
Nothing of that applies to this change.
> fix issues
Which weren't "issues" at all just this morning.
To your other issues, just do not upgrade. There is no need to upgrade everything a few days after release. I always lock ruff to version I like and upgrade whenever it is convenient.
> upgrade whenever it is convenient
In my codebase, and with my environment, the best answer is never. We'll have to pick a second-best answer though.
That is why gofmt is so great. As the saying goes: gofmt’s style is nobody’s favorite, yet gofmt is everybody’s favorite.
I'm not sure why people felt formatters were necessary. but now they're part of the zeitgeist and there is no going back.
It boggles me that anyone would argue against standardization, or believe that “just get hundreds of people to agree today and tomorrow and every future day” is a better solution.
It was essentially not an issue. Sometimes I’d grumble about someone, but it would never get in my way the way black or ruff would regularly.