Code formatting comes to uv experimentally

I'd rather `ruff` being merged with `ty` instead. `uv` for me is about package / project manager. It's not about code style. The only time `uv` should edit a code file is to update its dependencies (PEP 723).

On the other hand, both `ruff` and `ty` are about code style. They both edit the code, either to format or fix typing / lint issues. They are good candidates to be merged.

This is the direction I expected things to go, and not something I'm especially fond of. I'll stick with UNIX-philosophy tools, thanks.

There is wisdom in knowing when -- and how -- to break standards. Don't know if this is the case, but I think it is. If introducing fmt powers to UV meant it had to consider tradeoffs elsewhere where it might hurt its quality somehow then maybe, but in this case UV is more like an umbrella, unifying the interface for pip, venv, builds... And now fmt. All keeping each separate domain isolated without details leaking to one another.

What do I gain from adding 'uv' to the start of each of these commands, as opposed to having them all just be separate commands?

Abstraction. Not having to know all the innards (or even names) of each until you want to. It's all there if you want to, but stuff like uv (or cargo, or go's toolset) greatly simplifies 3 scenarios in particular: starting a new project, joining an existing project, and learning Python for the first time.

All 3 scenarios benefit from removing the choice of build tool, package manager, venv manager, formatter, linter, etc., and saying, "here, use this and get on with your life".

How is "uv format" a better name, or more "abstract", etc. etc., than "ruff check"? Why is it easier to think of my formatter and package manager (or whatever other pieces) as being conceptually the same tool, given that they are doing clearly different, independent and unrelated things?

And why is any of this relevant to first-time Python learners? (It's already a lot to ask that they have to understand version control at the same time that they're learning specific language syntax along with the general concept of a programming language....)

It’s an abstraction because it literally hides knowledge in service of presenting a more a more cohesive API to the human.

It requires less knowledge at the front end, which is when people are being bombarded with a ton of new things to learn.

Learners don’t have to even know what ruff is immediately. They just know that when they add “format” to the command they already know, uv, their code is formatted. At some later date when they know Python better and have more opinions, they can look into how and why that’s accomplished, but until then they can focus on learning Python.

uv isn’t a package manager only, its best thought of as a project manager, just like go or cargo. Its “one thing” is managing your Python project.

Would Linux similarly be better if we wrote e.g. "cu list" instead of "ls", "cu change" instead of "cd", etc.? (The "cu" stands for "coreutils", of course.) Because it seems to me like the same arguments apply. I was already thinking of uv as a "project manager" and I understand that intended scope, and even respect the undertaking. My point is that I don't believe that labeling all the tasks under that scope like this actually improves the UX.

Maybe I'm wrong about that. But I don't know that it can actually be A/B tested fairly, given network effects (people teaching each other or proselytizing to each other about the new way).