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.
We can replace the endless and useless discussion on how to format code with an endless and useless discussion on what linting tool to use.
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.
People tend to use tools set up in CICD and/or precommit. Without rules everyone uses their tool and is unwilling to compromise. Even if they are willing it is hard to setup tools to do exactly what you want. Default configuration is always the way.
So to the practical question: what we're gonna do today in CICD and/or precommit? "Default configuration is always the way" but which one: `ruff<0.16.0` or `ruff=0.16.0`?
I find it hard to look at ruff as at "other dependencies."
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.
I also do not like if project stays on 0 version to break compatibility with every minor version. This is the problem with many rust tools and libraries. I think it is unfair to do that years after first release and with healthy community. But it is a tradeoff and not using ruff is in my opinion worse.
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.
Why though? I've yet to come across an auto formatter that formats things the way I personally like. But that's fine. I do whatever the hell I want until I'm ready to open a PR, then bang it through the auto formatter. And you know what? I can also go the other direction and run a home-brew auto formatter to reshape things the way I personally want on my local machine.
I'm not sure why, but apparently my experience is unwelcome enough to be downvoted. Drive by changes are really annoying, IMO, and as the GP shows, the formatting tool outcome differs. So there are many "valid" versions of the same program logic. You have therefore not do what these formatters pretend to do, namely take this variable out of the equation. Rather, the wrong auto format can look much worse than the original.
I'm not sure why people felt formatters were necessary. but now they're part of the zeitgeist and there is no going back.
Gods forbid I talk to people I work with, learn their preferences, and figure out the way we can accommodate each other. Sounds like such a waste of energy. It’s so much better if we all acquiesce to the preferences of some people neither of works with!
I do not have strong aesthetic preference for code (I always disable "minimap" in editors which shows it because I think about code as symbols shown in "outline"). I would probably not notice reasonable code formatting change if you would do it during my holiday. My requirements for formatting are purely technical (ie. do not make unnecessary diffs on code change). But I have worked with a few programmers who think about code visually. They actually remember code structure and formatting more than text and use "minimap" instead of "outline". They also strongly oppose any automatic formatting and linters. It is fascinating how different some people are despite doing the same work.
How does that work when hundreds of people are working on a project, with a few new people joining every week?
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.
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.