Code formatting comes to uv experimentally

[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]

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

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

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

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

[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?

[alkh]

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]

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.

[darkamaul]

I don’t understand why adding a subcommand to uv is being considered bloat.

uv is already a complex tool, but it has excellent documentation. Adding a straightforward, self-explanatory subcommand like this doesn’t seem out of place.

[fluidcruft]

When talking about uv, this comes across similar to saying that "the 'make' command has too many targets".

[treyd]

Are they baked into the main executable or are they separate binaries (a la apt, cargo, etc)?

[IshKebab]

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]

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]

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.

[lugao]

Strong agree, they can even make the formatter configurable in pyproject if you want to use something else.

[rcarmo]

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

[asa400]

What's wrong with this approach specifically? Go does it this way. Rust does it this way. Elixir does it this way. It reduces the toil in setting up and using projects in those ecosystems substantially. It unifies community effort behind a common set of tools and provides beginners and experts alike with a shared entrypoint to projects.

[actinium226]

What is your first choice?

[Cogito]

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.

[kstrauser]

At that point I think you start wanting Makefiles, or preferably IMO justfiles. Then you can run `just format` and have it format your combined Python/SQL/Bash/TypeScript project.

[amanzi]

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]

ty is already in the same repo as ruff, so integrating seems likely

[infamia]

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]

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.

[calmbonsai]

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.

[rickydroll]

When is UVA going to start handling email?

[dirtbag__dad]

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.

[RossBencina]

Does it have to be "force" stuff up front? Surely there are less violent ways to ease new developers into conventions and tooling than the dictatorial approach.

[senand]

I use black and I like it. Where does ruff differ in terms of formatting?

[photios]

Love this! I would name it `uv fmt` and add `uv vet` to the roadmap too

[Calavar]

Why does a package manager need a formatter at all?

[btbytes]

The new `uv format` is just a shortcut for `uv run --with ruff ruff`.

[CoderJoshDK]

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.

[Kwpolska]

Why would a type checker need to call a package manager?

[vovavili]

Can't you just do this? Why bundle?

  uvx ruff format .

[ethan_smith]

The native integration offers persistent configuration, caching, and project-aware behavior that uvx (which just creates an ephemeral venv) doesn't provide.

[tspng]

It's not bundled. `uv format` will use the `ruff` binary and more or less run `uvx ruff format` behind the scene.

[IshKebab]

Because that's a way less obvious command.

[dkdcio]

that’s a bit slow typically

[nikisweeting]

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]

Also needs to make sorting imports a default.

[zahlman]

FWIW, you can pretty easily script this sort of thing. In Bash it can even be a function added to your ~/.bashrc .

[ayhanfuat]

> 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]

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]

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

[vorgol]

We can argue if it's a feature feature creep and if it's the right choice of formatter.

But let's appreciate that this will increase the use of formatters astronomically (or part thereof), which is an excellent thing.

[tomrod]

Oh neat. I wonder if they are integrating everything into uv then.