[thanhhaimai]

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.

[charliermarsh]

To clarify, `ruff` and `uv` aren't being merged. They remain separate tools. This is more about providing a simpler experience for users that don't want to think about their formatter as a separate tool.

The analogy would be to Cargo: `cargo fmt` just runs `rustfmt`, but you can also run `rustfmt` separately if you want.

[WD-42]

Thank you for writing software for all of us Python day-jobbers who wish we were writing Rust instead.

[drdaeman]

Isn’t there `uv tool run ruff` already for this? Or `uv run ruff` if it’s a proper dependency? I’m not sure what’s the point of a special shortcut command, unless there are plans to make it flexible so it’ll be an abstraction over formatters (unifying ruff, black, etc).

[godelski]

Is `uv format` supposed to be an alias for `ruff check`?

Stupidly I ran `uv format` without `--check` (no harm done and I can `git diff` it) so I didn't see the changes it made but `ruff check` does still show things that can be fixed with `ruff check --fix`. If I'm guessing correctly the difference is coming down to the fact that I have (in my submodule where all changes were made) a pyproject.toml file with ruff rules (there's also a .flake8 file. Repo is being converted). Either way, I find this a bit confusing userside. Not sure what to expect.

I think one thing I would like is that by default `uv format` spits out what files were changed like `uv format --check` does (s/Would reformat/Reformatted/g). Fine for the actual changes not to be displayed but I think this could help with error reduction. Running it again I can see it knows 68 files were changed. Where is that information being stored? It's pretty hard to grep out a number like that (`grep -R \<68\>`) and there's a lot of candidates (honestly there's nothing that looks like a good candidate).

Also, there's a `--quiet` flag, but the output is already pretty quiet. As far as I can tell the only difference is that quiet suppresses the warning (does `--quiet` also suppress errors?)

  uv format
  warning: `uv format` is experimental and may change without warning. Pass `--preview-features format` to disable this warning.
  36 files reformatted, 31 files left unchanged

  uv format --quiet
  36 files reformatted, 31 files left unchanged

I like the result for `--quiet` but I have a strong preference that `uv format` match the verbosity of `uv format --check`. I can always throw information away but not recover. I have a strong bias that it is better to fail by displaying too much information than fail by displaying too little. The latter failure mode is more harmful as the former is much more easily addressed by existing tools. If you're taking votes, that's mine.

Anyways, looking forward to seeing how this matures. Loved everything so far!

[slightwinder]

> To clarify, `ruff` and `uv` aren't being merged.

ruff at least seems to be compiled into uv, as the format worked here without a local ruff. This is significant more than just an interface. Whether they are managed and developed as separate tools doesn't matter.

> This is more about providing a simpler experience for users that don't want to think about their formatter as a separate tool.

Then build a separate interface, some script/binary acting as a unified interface, maybe with its separate distribution of all tools. Pushing it into uv is just adding a burden to those who don't want this.

uv and ruff are poor names anyway, this could be used to at least introduce a good name for this everything-python-tool they seem to aim for.

[jgauth]

This is cool. Is there a way to call ruff’s linter? Like `uv lint`, which would call `ruff check`.

To your analogy, it’d be like `cargo clippy`

[rbits]

Does it have the capability to use a different formatter than ruff?

[WD-42]

They are mimicking Rust's cargo, which has `cargo fmt`

[Biganon]

> They are mimicking Rust's cargo

Cargo cargo cult?

[munificent]

Also `go fmt` and `dart format`.

[petcat]

Doesn't cargo just have a subcommand plugin system? Or is fmt actually hard-coded into the cargo code?

I prefer the plugin system. I don't like god programs like what the npm monstrosity became.

[impulser_]

I think the goal is to make uv a complete package manager for Python while still giving you the option to use the parts separately.

uv is like cargo for python.

If you only need a fast type checker you can just use ty, if you just need a fast formatter and linter you can just use ruff.

Combining ruff and ty doesn't make sense if you think about like this.

[RossBencina]

Including a formatter in a package manager doesn't make sense to me. Seems like obvious feature creep.

My understanding was that uv is for installing dependencies (e.g. like pip) with the added benefit of also installing/managing python interpreters (which can be reasonably thought of as a dependency). This makes sense. Adding more stuff doesn't make sense.

[baggiponte]

i think it's good to let them experiment! cargo (and go?) offers this already, so why not.

[munro]

But what if `ty` was also eventually merged into `uv` as well? 8-)

That's probably the vision, given all from astral.sh, but `ty` isn't ready yet.

[alfalfasprout]

Oh please no...

The reality is, ecosystems evolve. First, we had mypy. Then more type checkers came out: pyre, pyright, etc. Then basedpyright. The era of rust arrived and now we have `ty` and `pyrefly` being worked on heavily.

On the linter side we saw flake8, black, and then ruff.

Decoupling makes adapting to evolution much easier. As long as both continue to offer LSP integrations it allows engineers to pick and chose what's best.

[d0mine]

The whole premise of uv that you don't need to know that you can install specific python version using eg pyenv (`uv python install` or `uv run` may do it implicitly), you don't need to know about `python -m venv`/virtualenv (`uv venv`), or how to create lock files pip-tools / pipenv / poetry / etc(`uv lock`), or pipx (`uv tool install`) or `pip install`/ `pipenv install`/`poetry add` / many others (`uv add`), or how to build artifacts setuptools / hatchling / poetry way / etc (`uv build`). Other commands such as `uv sync` didn't break new ground too.

`uv format` is similar (you don't need to know about `ruff format` / black / yapf ).

[zahlman]

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]

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.

[gchamonlive]

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.

[Kinrany]

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]

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

[darkamaul]

And I would think the next logical step here is to have a `uv lint` option here that runs ˋty` under the hood ?

I would love to see a world where there is a single or a set of standard commands that would prepare your python project (format, lint, test, publish). Maybe that’s the vision here?