Comment by zem

2 days ago

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

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

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

    • Or maybe some prefer random versions of dependencies being downloaded and running over our code?