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 · 3h ago
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 · 3h ago
Thank you for writing software for all of us Python day-jobbers who wish we were writing Rust instead.
drdaeman · 3h ago
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).
charliermarsh · 2h ago
Yeah, you can definitely use `uvx ruff` (an alias for `uv tool run ruff`) to invoke Ruff. That's what I've done in my own projects historically.
The goal here is to see if users like a more streamlined experience with an opinionated default, like you have in Rust or Go: install uv, use `uv init` to create a project, use `uv run` to run your code, `uv format` to format it, etc. Maybe they won't like it! TBD.
(Ruff is installed when you invoke `uv format`, rather than bundled with the uv binary, so if you never use `uv format`, there aren't any material downsides to the experiment.)
divbzero · 3m ago
> (Ruff is installed when you invoke `uv format`, rather than bundled with the uv binary, so if you never use `uv format`, there aren't any material downsides to the experiment.)
That’s thoughtful design and could be worth mentioning in the blog post.
chippiewill · 2h ago
It's part of the mission for uv to become "cargo for python". A one stop swiss-army knife for everything you need to manage a Python project. I think it'll get a `uv test` command at some point too.
The whole point is you just install `uv` and stop thinking about the pantheon of tools.
robertlagrant · 2h ago
It'll be interesting to see how the test is done. At the tox level, or the pytest level? (Or another level?) I can see all being useful and ergonomic, but tox's multi-environment setup might fit into it really well.
jgauth · 56m ago
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`
WD-42 · 3h ago
They are mimicking Rust's cargo, which has `cargo fmt`
munificent · 3h ago
Also `go fmt` and `dart format`.
impulser_ · 3h ago
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.
zahlman · 3h 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.
gchamonlive · 16m ago
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.
zem · 3h 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.
zahlman · 2h ago
I don't think this is an apt (pun intended?) comparison at all.
munro · 3h ago
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 · 51m ago
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.
Cogito · 11m ago
I anticipate this will make it much easier for me to get my little team of actuaries formatting their code.
The impact of uv on our onboarding and utilisation of python has already been huge, and any way I can easily improve their code hygiene is a good one. Yes, I could get them to use ruff standalone, or set up pre-commit hooks etc for them, but the simple mental model that comes from `uv <do something>` is really beneficial.
Will have a play around with this and see how it goes. Would love to be able to hook into other formatters too, but not sure if that's easy or even possible already. For example, I would love it if `uv format` also formatted our SQL/dbt models.
ayhanfuat · 4h ago
> an experimental new command that Python developers have been waiting for: uv format
Have developers really been waiting for this? What's wrong with ruff format?
chippiewill · 2h ago
I've been waiting.
uv is trying to deliver the same experience as cargo does for rust. Just install a single CLI and it's the only tool you have to worry about when working on your Python project.
There's nothing wrong with `ruff format`, but it's nice to have `uv` as a universal entrypoint.
loloquwowndueo · 4h ago
> Try out uv format in your next project and see how it fits into your development workflow. The experimental nature means your feedback could help shape how this feature evolves.
So maybe nobody has been waiting for this and the feedback will be: we don’t need this.
Also it uses ruff under the hood. If it’s integrated with uv, an advantage is one less tool to juggle.
jsight · 3h ago
I've been playing around with go quite a bit lately, and now think that being bundled is actually a really serious advantage.
Being able to just to "go fmt", without needing any additional tools, is a really great thing about the language.
The only danger that I can see (and it is a big one) is that Python doesn't have the same kind of consistency that go does. It might end up failing just because so many people use Python in such different ways.
worldsayshi · 3h ago
Yes, one advantage is that tools/editors will start to standardize on it. I quite enjoyed the seamless experience of go formatting as I started learning go. It felt like one less thing to worry about. Just worked.
mintplant · 3h ago
Well, the same functionality used to be bundled into rye before the switch to uv. I appreciate having one less dependency to declare again.
alkh · 3h ago
I enjoy using uv a lot but am getting afraid that it is getting bloated for no reason. For ex., the number of niche flags that a lot of subcommands support is very high + some of them seemingly achieve the same result(uv run --no-project and uv run --active). I'd rather them working on improving existing tools and documentation than adding new (redundant) functionality
benreesman · 3h ago
It's really difficult to do Python projects in a sound, reproducible, reasonably portable way. uv sync is in general able to build you only a package set that it can promise to build again.
But it can't in general build torch-tensorrt or flash-attn because it has no way of knowing if Mercury was in retrograde when you ran pip. They are trying to thread a delicate an economically pivotal needle: the Python community prizes privatizing the profits and socializing the costs of "works on my box".
The cost of making the software deployable, secure, repeatable, reliable didn't go away! It just became someone else's problem at a later time in a different place with far fewer degrees of freedom.
Doing this in a way that satisfies serious operations people without alienating the "works on my box...sometimes" crowd is The Lord's Work.
treyd · 3h ago
Are they baked into the main executable or are they separate binaries (a la apt, cargo, etc)?
charliermarsh · 3h ago
It's a separate binary -- we install Ruff if you invoke `uv format`. So if you don't invoke `uv format`, there's no impact on the binary size, etc.
lxe · 2m ago
uv is taking bun's route and just adding features "willy-nilly"?
amanzi · 3h ago
It wouldn't surprise me if the ruff featurset eventually gets integrated into uv and ty. The linting seems to better suited to ty which would be able to provide more intelligent linting since it understands the codebase better. And the formatting seems better suited to uv since that's all about managing your project.
IAmLiterallyAB · 3h ago
ty is already in the same repo as ruff, so integrating seems likely
IshKebab · 3h ago
This is obviously a great move. I don't know why so many commenters here are against making things better. "Can't you just do <this slightly worse thing> already?". Well yes. But it's slightly worse.
wasabi991011 · 18m ago
I don't think being one word longer ("uvx ruff format" vs "uv format") counts as being is worse.
I think it is much worse to create a special case that obscures the actual formatter being run and how it is being run (is ruff now preinstalled, or is it downloaded and cached in the same way as other tools?)
Spivak · 2h ago
I think the biggest thing is that it doesn't seem to support other formatters. If my project uses black I don't get to have uv format work for me.
right, but you definitely shouldn’t be using any other formatter than ruff and this helps with that
rickydroll · 3h ago
When is UVA going to start handling email?
rcarmo · 4h ago
This feels like feature creep. I've been using uv more and more over the past year (mostly because I work with projects that use it) and although I like it and recognize the advantages, it is still not my first choice, and this kind of thing isn't going to help that...
actinium226 · 3h ago
What is your first choice?
infamia · 2h ago
Mixing a package manager, (which is needed for prod package installs) with dev-only tooling is analogous to an "attractive nuisance" (not that I'm saying anyone is a child mind). I know Go and Rust do it, but thinking from first principles, it sounds like a bad idea.
kstrauser · 2h ago
It really does sound like a bad idea, and now that I've used cargo a lot, I want a lot more of those bad ideas in my life.
Seriously, if uv becomes to Python what cargo is to Rust, the developer experience for Python is going to be vastly better than before. I've been writing Python professionally for more than 25 years, and getting paid to work around it's crummier parts, and I'm thrilled to be able to throw away all that knowledge and just use uv.
dirtbag__dad · 22m ago
Having worked with many python repos, that didn’t know any better to follow conventions or that the tooling ecosystem has meaningful options, I am ecstatic to see formatting and linting be a first class feature of the modern python experience.
I know this is a hot take, but so much headache saved down the road to “force” this stuff up front.
CoderJoshDK · 3h ago
internally, they are working on ty and some of its logic is going to have to call out to uv. I imagine that things like this is being built to experiment with some of the connections and interfaces between tools.
The astral team is pretty responsive to questions and feedback. If this type of change concerns you (as an actual user of the tool) please reach out to them. My big thing right now is integrations with workspaces. And if special case commands is the answer,,, well not ideal but I’ll take it.
calmbonsai · 3h ago
I see zero need for this given that excellent time-testing code formatting tooling options are already available.
This smacks of feature-creep and I won't be incorporating it into any pipelines for the foreseeable future.
charliermarsh · 2h ago
`uv format` is just a front-end for `ruff format`. It isn't introducing a new formatter to the ecosystem or anything like that.
nikisweeting · 2h ago
You realize this is just a shortcut for one of those "time-tested" options, right? ruff format is already widely used.
calmbonsai · 1h ago
But why bundle? It makes zero design sense to me.
nikisweeting · 1m ago
go fmt, cargo fmt, deno fmt, dart format, etc. it's hardly a new trend to ship a formatter with an all-in-one package manager for a language. It's convenient for new projects to not have to set up an additional dependency.
vovavili · 3h ago
Can't you just do this? Why bundle?
uvx ruff format .
IshKebab · 3h ago
Because that's a way less obvious command.
dkdcio · 3h ago
that’s a bit slow typically
replygirl · 3h ago
so install ruff?
nikisweeting · 3h ago
As long as it does `ruff check --fix; ruff format` internally and not just one or the other, then I'm happy. Tired of running 2 commands every time.
0cf8612b2e1e · 3h ago
Also needs to make sorting imports a default.
nikisweeting · 3h ago
and stop removing extra leading whitespace before inline comments (#7684)
zahlman · 3h ago
FWIW, you can pretty easily script this sort of thing. In Bash it can even be a function added to your ~/.bashrc .
nikisweeting · 3h ago
Of course we already have it automated in pre-commit checks, I'm just mildly annoyed that it's two different commands in the first place (though I'm sure there is some good historical reason). The distinction/ordering between them isn't really clear as a user, I just want "find and fix everything you can, error if you cant autofix" every time.
IshKebab · 3h ago
Just so you know, when people say "I hate this paper cut", they aren't really asking how they can put in extra work to get around it. Obviously hey can add some alias to ~/.bashrc... on every computer he uses. The complaint is that he has to do that in the first place. It's still annoying.
zahlman · 2h ago
I prefer having things this way, because it respects the fact that I may have a different idea from the next person about how the pieces should be put together.
aseipp · 2h ago
OK and the vast majority of people excluding you and them probably have a very close-or-nearly-identical idea about what should happen. So everyone can be happy, there's nothing being lost here.
nikisweeting · 2h ago
no one is proposing removing the sub-commands, only adding a shortcut that calls both
Calavar · 4h ago
Why does a package manager need a formatter at all?
kristjansson · 4h ago
Is cargo just a package manager? Go?
Calavar · 3h ago
Cargo is a hybrid of package manager and build system. So it has frontend fommands wrapping a formatter and loads of other stuff, like code linters, as part of the build system. I've used cargo to build projects even when they have no dependencies and I don't plan to bundle them up and publish them as crates.
Ok, but we will go a step further and also integrate the remaining of ruff features? Because we have `go vet`. Does it even make sense to have the linter integrated too?
I am not sure I like this either. I think linter and formatter are more like developer dependencies, especially because both formatter and linters are generally things that you want to lock to a specific version to avoid e.g. CI failures or mass changes when a version is updated. But I can understand that having a formatter always available may be nice.
nomel · 1h ago
Careful, we're going to end up with some integrated development environment, that has all these things working nicely together!
tomrod · 3h ago
Oh neat. I wonder if they are integrating everything into uv then.
time0ut · 1h ago
Cool. I want a do it all python tool. Ruff is great. Having it out of the box with uv is great. Less crap to mess with. I haven’t tried ty yet, but looking forward to not having to mess with pyright.
Wary of the vc funded aspect though…
cwyers · 3h ago
The HN commenters in a nutshell:
ruff: Aww, you're sweet!
uv format: Hello, human resources?
Meanwhile, they provide identical functionality. (`Under the hood, it calls Ruff’s formatter to automatically style your code according to consistent standards.`)
0cf8612b2e1e · 3h ago
But why do it? Keep each tool focused on its specific goal. Will there eventually be a call to deprecate ruff because it already exists in uv?
Both tools are still evolving enough that I would not want their individual release cycles to impact each other.
charliermarsh · 3h ago
Good questions. I don't think we'd ever deprecate Ruff because `uv format` exists, and adding `uv format` won't have any impact on Ruff's release cycles or development. The analogy would be to Cargo: `cargo fmt` just runs `rustfmt`, but you can also run `rustfmt` separately if you want.
A lot of users just want a simpler experience. They want to install uv, run `uv run` to run their project, `uv format` to format it, etc. The idea here is to experiment with providing that functionality and see if folks find it useful. Maybe they won't want it! It's experimental :)
comradesmith · 2h ago
Cause one is a formatter and the other is a package manager. That shouldn’t be hard to understand.
nikisweeting · 2h ago
Package managers providing a shortcut to call a standardized formatter is a very popular feature in many languages, also not hard to understand the appeal:
- cargo fmt
- go fmt
- deno fmt
- dart format
chippiewill · 2h ago
`uv` isn't a package manager (that's the `uv-pip` sub command), it's a project manager. It's meant to manage all aspects of the project.
zahlman · 3h ago
Memes aside, the conceptual grouping of tools does matter.
replygirl · 3h ago
i expect to hear "hey replygirl, can we upgrade from ruff to uv format?" from 5 of my coworkers in the next month, and "what's the difference between ruff and uv format?" from another 10. per interaction i expect 2 minutes of reading and explaining, plus an average 5 minutes listening to the other party wax philosophical. so the convenience costs my job $400
cwyers · 2h ago
I'm just going to ask this: if your coworkers ask "can we upgrade from ruff to uv format," and it takes you that much time to explain it, have you just considered going "sure thing," spending two hours on Twitter, and pushing a commit and getting paid for it?
replygirl · 2h ago
now i've spent 2 minutes implementing, 1 minute drafting and assigning the pr, 10 minutes checking everything, 10 minutes each of two reviewers' time, 10 minutes of qa's time, and 1 minute reporting. it's also likely i spend 2 minutes explaining what it is to each of our PMs and our CTO and why they don't need to worry about it. then i still need to field questions from devs, this time "why did we change this?" and still "what's the difference?". so that costs the company even more.
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.
The analogy would be to Cargo: `cargo fmt` just runs `rustfmt`, but you can also run `rustfmt` separately if you want.
The goal here is to see if users like a more streamlined experience with an opinionated default, like you have in Rust or Go: install uv, use `uv init` to create a project, use `uv run` to run your code, `uv format` to format it, etc. Maybe they won't like it! TBD.
(Ruff is installed when you invoke `uv format`, rather than bundled with the uv binary, so if you never use `uv format`, there aren't any material downsides to the experiment.)
That’s thoughtful design and could be worth mentioning in the blog post.
The whole point is you just install `uv` and stop thinking about the pantheon of tools.
To your analogy, it’d be like `cargo clippy`
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.
That's probably the vision, given all from astral.sh, but `ty` isn't ready yet.
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.
The impact of uv on our onboarding and utilisation of python has already been huge, and any way I can easily improve their code hygiene is a good one. Yes, I could get them to use ruff standalone, or set up pre-commit hooks etc for them, but the simple mental model that comes from `uv <do something>` is really beneficial.
Will have a play around with this and see how it goes. Would love to be able to hook into other formatters too, but not sure if that's easy or even possible already. For example, I would love it if `uv format` also formatted our SQL/dbt models.
Have developers really been waiting for this? What's wrong with ruff format?
uv is trying to deliver the same experience as cargo does for rust. Just install a single CLI and it's the only tool you have to worry about when working on your Python project.
There's nothing wrong with `ruff format`, but it's nice to have `uv` as a universal entrypoint.
So maybe nobody has been waiting for this and the feedback will be: we don’t need this.
Also it uses ruff under the hood. If it’s integrated with uv, an advantage is one less tool to juggle.
Being able to just to "go fmt", without needing any additional tools, is a really great thing about the language.
The only danger that I can see (and it is a big one) is that Python doesn't have the same kind of consistency that go does. It might end up failing just because so many people use Python in such different ways.
But it can't in general build torch-tensorrt or flash-attn because it has no way of knowing if Mercury was in retrograde when you ran pip. They are trying to thread a delicate an economically pivotal needle: the Python community prizes privatizing the profits and socializing the costs of "works on my box".
The cost of making the software deployable, secure, repeatable, reliable didn't go away! It just became someone else's problem at a later time in a different place with far fewer degrees of freedom.
Doing this in a way that satisfies serious operations people without alienating the "works on my box...sometimes" crowd is The Lord's Work.
I think it is much worse to create a special case that obscures the actual formatter being run and how it is being run (is ruff now preinstalled, or is it downloaded and cached in the same way as other tools?)
Seriously, if uv becomes to Python what cargo is to Rust, the developer experience for Python is going to be vastly better than before. I've been writing Python professionally for more than 25 years, and getting paid to work around it's crummier parts, and I'm thrilled to be able to throw away all that knowledge and just use uv.
I know this is a hot take, but so much headache saved down the road to “force” this stuff up front.
The astral team is pretty responsive to questions and feedback. If this type of change concerns you (as an actual user of the tool) please reach out to them. My big thing right now is integrations with workspaces. And if special case commands is the answer,,, well not ideal but I’ll take it.
This smacks of feature-creep and I won't be incorporating it into any pipelines for the foreseeable future.
I don't know much about go.
https://docs.astral.sh/uv/concepts/build-backend/
I am not sure I like this either. I think linter and formatter are more like developer dependencies, especially because both formatter and linters are generally things that you want to lock to a specific version to avoid e.g. CI failures or mass changes when a version is updated. But I can understand that having a formatter always available may be nice.
Wary of the vc funded aspect though…
ruff: Aww, you're sweet!
uv format: Hello, human resources?
Meanwhile, they provide identical functionality. (`Under the hood, it calls Ruff’s formatter to automatically style your code according to consistent standards.`)
Both tools are still evolving enough that I would not want their individual release cycles to impact each other.
A lot of users just want a simpler experience. They want to install uv, run `uv run` to run their project, `uv format` to format it, etc. The idea here is to experiment with providing that functionality and see if folks find it useful. Maybe they won't want it! It's experimental :)
- cargo fmt
- go fmt
- deno fmt
- dart format