Comment by zahlman
2 days ago
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.
2 days ago
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.
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.
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).
I don't think this is an apt (pun intended?) comparison at all.
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
4 replies →
If I want to call ruff, I can do so myself. Why should I want to call it through uv?
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
Some of us prefer well packaged tool that does everything instead of stitching together bazillions of dependencies.
1 reply →
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".
5 replies →
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?
Well for one thing separate commands that are as good as what uv does don’t exist
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
I mean, Go was designed by one of the authors of UNIX, and that has very much batteries-included tooling.
So UNIXy that he didn't even like long options (--option) in the standard flag library.
Long options are more of a GNU thing and GNU's Not Unix.
[dead]