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.

▲ zem 5 days ago | parent | next [-]

this is very much in line with the unix philosophy - it delegates formatting to ruff and simply provides a unified front end that calls out to the right specialized tool. think of it as a makefile.

▲

zvr 4 days ago | parent | next [-]

A better example might be: in good ol' days when we were formatting with troff(1), passing arguments to the command line invoked other programs like eqn(1) and tbl(1).

▲

zahlman 5 days ago | parent | prev | next [-]

I don't think this is an apt (pun intended?) comparison at all.

▲

d0mine 4 days ago | parent [-]

One can find repos using `make format` / `make lint`/ `make typecheck` / or similar

I remember David Beazley mentioning that code with Makefiles were relatively easier to analyze based on ~Terabyte of C++ code and no internet connection (pycon 2014) https://youtube.com/watch?v=RZ4Sn-Y7AP8

▲

Kwpolska 4 days ago | parent [-]

That `make format` command was not defined by the Make developers, but by the team using Make in their project. They picked their favorite formatter and defined a shortcut. In this case, the uv developers are forcing the command on everyone, and they're using it to cross-promote their own formatting tool.

	▲	Hendrikto 4 days ago \| parent \| next [-]
		They are not forcing anything on anyone. You can decide to never run `uv format` and ruff won’t even be installed. You can use uv without ruff. You can use ruff without uv. You can invoke ruff yourself if that’s what you want. Or use any other formatter. I don’t think I understand what your complaint is.
	▲	asa400 4 days ago \| parent \| prev \| next [-]
		Other people having an opinion and creating their own software project to implement it is not “forcing” anyone to do anything. The inverse would be no one is allowed to create any projects that you don’t personally agree with.
	▲	wiseowise 4 days ago \| parent \| prev [-]
		Nobody is forcing you to use anything. Feel free to ignore it and use whatever flavor you like.

▲

zelphirkalt 4 days ago | parent | prev [-]

If I want to call ruff, I can do so myself. Why should I want to call it through uv?

▲

woodruffw 4 days ago | parent | next [-]

If you want to call ruff directly, this doesn't change anything. It's a purely optional feature.

However, to answer the question generally: people want this for the same reason that most people call `cargo fmt` instead of running rustfmt[1] directly: it's a better developer experience, particularly if you don't already think of code formatting as an XY-type problem ("I want to format my code, and now I have to discover a formatter" versus "I want to format my code, and my tool already has that").

[1]: https://github.com/rust-lang/rustfmt

▲

wiseowise 4 days ago | parent | prev [-]

Some of us prefer well packaged tool that does everything instead of stitching together bazillions of dependencies.

	▲	zelphirkalt 4 days ago \| parent [-]
		Or maybe some prefer random versions of dependencies being downloaded and running over our code?

▲ gchamonlive 5 days ago | parent | prev | next [-]

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.

▲ zahlman 4 days ago | parent [-]

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?

▲ asa400 4 days ago | parent | next [-]

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".

▲ zahlman 4 days ago | parent [-]

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....)

▲ asa400 4 days ago | parent | next [-]

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.

▲

zahlman 4 days ago | parent [-]

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).

	▲	woodruffw 4 days ago \| parent [-]
		I don't think Linux would be better with a `cu` prefix for coreutils, but I do think git would be worse without a `git` prefix. I think it's ultimately a question of user expectations, and I think user expectations around packaging tooling in particular have shifted towards the Go and Rust styles of providing a "namespace" tool that provides a single verb-style interface for developer actions.

▲ ChadNauseam 4 days ago | parent | prev [-]

the meaning of the word "ruff" has nothing to do with formatting. Therefore it's harder to remember than "format". if they could just call the formatter "format", that would be best, but obviously that name is too overloaded. So they namespace it under a tool people already know, "uv".

Let's imagine you're learning a new language, which has tools with names that I just made up. Which has a clearer pattern to you?

    1. Check code with  `blargle check`
    2. Format code with `blargle format`
    3. Run code with    `blargle run`

    1. Check code with  `zoop`
    2. Format code with `chungus`
    3. Run code with    `kachow`

Clearly, the first is easier to remember. The benefit of namespacing is that you only need to remember one weird/unique name, and then everything under that can have normal names. If you don't have namespacing, you need weird/unique names for every different tool.

▲ bowsamic 4 days ago | parent | prev | next [-]

Well for one thing separate commands that are as good as what uv does don’t exist

▲ gchamonlive 4 days ago | parent | prev [-]

I also don't know what I'd gain, but it doesn't mean there isn't practical use for someone else.

But most importantly, apart from breaking away from "UNIX-philosophy tools", what do you lose in practical terms?

▲ Kinrany 4 days ago | parent | prev | next [-]

The spirit of the unix philosophy is not implementing MxN use cases separately. Running the same program as a separate binary or as a subcommand has nothing to do with it

▲ cedws 4 days ago | parent | prev | next [-]

I mean, Go was designed by one of the authors of UNIX, and that has very much batteries-included tooling.

▲

lenkite 4 days ago | parent [-]

So UNIXy that he didn't even like long options (--option) in the standard flag library.

	▲	ksherlock 4 days ago \| parent [-]
		Long options are more of a GNU thing and GNU's Not Unix.

▲ smohare 5 days ago | parent | prev [-]

[dead]