Comment by asa400
1 day ago
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).
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.