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.
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.
API-first or API-only backends are a sweet spot for today's Rust, IMO, and its resource footprint, reduced maintenance long-tail, and performance properties are all super competitive. It's especially hard to find another language that can compete with Rust on all three of those at once.
I'd like to hear more about that. I'm also curious what makes Rust particularly suited to "API-first" backends. My understanding of the language is that it's concurrency primitives are excellent but difficult to learn and it's gc-less runtime.
> it's concurrency primitives are excellent but difficult to learn
They're actually incredibly easy to learn if your software paradigm is the request-response flow.
The borrow checker might kill your productivity if you're writing large, connected, multi-threaded data structures, but that simply isn't the nature of 90% of services.
If you want to keep around global state (db connectors, in-memory caches, etc.) Arc<Mutex<T>> is a simple recipe that works for most shared objects. It's dead simple.
You can think of Rust with Axum/Actix as a drop-in replacement for Go or Python/Flask. With the added benefits of (1) no GC / bare metal performance, (2) much lower defect rate as a consequence of the language ergonomics, (3) run it and forget it - no GC tuning, very simple scaling.
Rust has effectively made writing with the performance of C++ feel like writing Ruby, but with unparalleled low defect rates and safety on account of the type system.
>Rust has effectively made writing with the performance of C++ feel like writing Ruby, but with unparalleled low defect rates and safety on account of the type system.
This is a little overblown.. speaking VERY HAND-WAVILY, sea_orm < active record by a factor of about 10x more mental overhead but is at least that much more performant...
but yea, vibe-coding rust micro services is pretty amazing lately, almost no interactions with borrow checker, and I'm even using cucumber specs...
I currently wouldn't recommend any Rust ORM, Diesel included. They're just not quite ready for prime time.
If you're not one to shy away from raw SQL, then SQLx is rock-solid. I actually prefer it over ORMs in general. It's type-checked at runtime or compile time against your schema, no matter how complex the query gets. It manages to do this with an incredibly simple design.
It's like an even nicer version of Java's popular jOOQ framework, which I always felt was incredibly ugly.
SQLx might be my very favorite SQL library of any language.
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).
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.)
> (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.
Would you ever consider bundling ruff binaries with uv releases similar to uvx and uvw? It would benefit offline users and keep compatible uv/ruff versions in sync.
Perhaps even better… cargo-like commands such as uv check, uv doc, and uv test could subsume ruff, ty, and other tools that we haven’t seen yet ;)
A pyup command that installs python-build-standalone, uv, python docs, etc. would be totally clutch, as would standalone installers [0] that bundle it all together.
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.
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.
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!
That makes some more sense. I think I just misunderstood what Charlie was saying above.
But I'll also add another suggestion/ask. I think this could be improved
$ ruff format --help
Run the Ruff formatter on the given files or directories
$ uv format --help
Format Python code in the project
I think just a little more can go a long way. When --help is the docs instead of man I think there needs to be a bit more description. Just something like this tells users a lot more
$ ruff format --help
Formats the specified files. Acts as a drop-in replacement for black.
$ uv format --help
Experimental uv formatting. Alias to `ruff format`
I think man/help pages are underappreciated. I know I'm not the only one that discovers new capabilities by reading them. Or even the double tab because I can't remember the flag name but see something I didn't notice before. Or maybe I did notice before but since the tool was new I focused on main features first. Having the ability to read enough information to figure out what these things do then and there really speeds up usage. When the help lines don't say much I often never explore them (unless there's some gut feeling). I know the browser exists, but when I'm using the tool I'm not in the browser.
> 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.
ruff is not compiled into uv; it's bootstrapped from an independent build, much like how `cargo fmt` is bootstrapped from a separate toolchain component (rustfmt). You can see how that works in the PR[1]. Importantly, that means that you don't experience any build-, install-, or run-time burden if you don't use this subcommand.
cargo has an external subcommand system, but it also has "blessed" (my word choice) external subcommands that are typically bootstrapped via Rust toolchain components. This makes them pretty analogous to what uv does here with `uv format`, in my opinion.
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.
One of the maintainers said in another comment that it will download the formatter (ruff) and it is not embedded. So if you don't use that feature you won't even notice:
https://news.ycombinator.com/item?id=44978660
I’m sure you’re a old man on the verge of death who loves yelling at clouds but enforcement and application of consistent code formatting has been considered a basic part of project management for a while now. Recent langage provide it as part of core project management tooling.
Given uv is openly strongly inspired by cargo and astral also has tooling for code formatting, the integration was never a question of “if”.
I remember how in a previous job the code formatter cost me time and time again. I already intentionally format my code as it makes sense and with the goal of improving readability. Then the damn auto formatter comes along and destroys this, by splitting a log call over 5 lines, because it has seen, that the log call is longer than 80 characters. Thank you for wasting 5 LoC of screen space for something that is a sidenote basically. That'll surely improve readability. So what do people do? They increase line length to 200 characters, to avoid this shit happening. Only that now it does no longer break long lines that should be broken. Unless I added trailing comma everywhere, wasting more time to make the formatter behave properly.
I am not against auto formatters in general, but they need to be flexible and semantically aware. A log call is not the same as other calls in significance. If the auto formatter is too silly to do that, then I prefer no auto formatter at all and keep my code well formatted myself, which I do anyway while I am writing the code. I do it for my own sake and for anyone who comes along later. My formatting is already pretty much standard.
Doing a lot of Rust, there is one huge benefit of having cargo handle rustfmt: it knows the fileset you're talking about. It will not blindly format all rust files in the cwd, rather the "current" crate (current having the same definition as cargo!).
Translating this to uv, this will streamline having multiple python packages in the same directory/git repo, and leave e.g. vendored dependencies alone.
Also, since their goal really is "making cargo for python", it will likely support package-scoped ruff config files, instead of begin file- or directory-based.
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 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 ).
All actions listed in your first paragraph, except for installing specific Python versions, are actions related to the area of packaging. Doing it in one tool is completely sensible. I'm not a fan of uv managing Pythons, but I guess that ship has sailed.
But formatting code is a completely new area that does not fit uv.
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?
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).
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.
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").
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.
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".
How is "uv format" a better name, or more "abstract", etc. etc., than "ruff check"? Why is it easier to think of my formatter and package manager (or whatever other pieces) as being conceptually the same tool, given that they are doing clearly different, independent and unrelated things?
And why is any of this relevant to first-time Python learners? (It's already a lot to ask that they have to understand version control at the same time that they're learning specific language syntax along with the general concept of a programming language....)
It’s an abstraction because it literally hides knowledge in service of presenting a more a more cohesive API to the human.
It requires less knowledge at the front end, which is when people are being bombarded with a ton of new things to learn.
Learners don’t have to even know what ruff is immediately. They just know that when they add “format” to the command they already know, uv, their code is formatted. At some later date when they know Python better and have more opinions, they can look into how and why that’s accomplished, but until then they can focus on learning Python.
uv isn’t a package manager only, its best thought of as a project manager, just like go or cargo. Its “one thing” is managing your Python project.
Would Linux similarly be better if we wrote e.g. "cu list" instead of "ls", "cu change" instead of "cd", etc.? (The "cu" stands for "coreutils", of course.) Because it seems to me like the same arguments apply. I was already thinking of uv as a "project manager" and I understand that intended scope, and even respect the undertaking. My point is that I don't believe that labeling all the tasks under that scope like this actually improves the UX.
Maybe I'm wrong about that. But I don't know that it can actually be A/B tested fairly, given network effects (people teaching each other or proselytizing to each other about the new way).
I don't think Linux would be better with a `cu` prefix for coreutils, but I do think git would be worse without a `git` prefix. I think it's ultimately a question of user expectations, and I think user expectations around packaging tooling in particular have shifted towards the Go and Rust styles of providing a "namespace" tool that provides a single verb-style interface for developer actions.
the meaning of the word "ruff" has nothing to do with formatting. Therefore it's harder to remember than "format". if they could just call the formatter "format", that would be best, but obviously that name is too overloaded. So they namespace it under a tool people already know, "uv".
Let's imagine you're learning a new language, which has tools with names that I just made up. Which has a clearer pattern to you?
1. Check code with `blargle check`
2. Format code with `blargle format`
3. Run code with `blargle run`
Or
1. Check code with `zoop`
2. Format code with `chungus`
3. Run code with `kachow`
Clearly, the first is easier to remember. The benefit of namespacing is that you only need to remember one weird/unique name, and then everything under that can have normal names. If you don't have namespacing, you need weird/unique names for every different tool.
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 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
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.
> 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.
This is a self-inflicted wound, since flash attention insist on building a native C++ extension which is completely unnecessary in this case.
What you can do is the following:
1) Compile your CUDA kernels offline.
2) Include those compiled kernels in a package you push to pypi.
3) Call into the kernels with pure Python, without going through a C++ extension.
I do this for the CUDA kernels I maintain and it works great.
Flash attention currently publishes 48 (!) different packages[1], for different combinations of pytorch and C++ ABI. With this approach it would have to only publish one, and it would work for every combination of Python and pytorch.
While shipping binary kernels may be a workaround for some users, it goes against what many people would consider "good etiquette" for various valid reasons, such as hackability, security, or providing free (as in liberty) software.
Shipping binary artifacts isn't inherently a bad thing - that's what (most) Linux Distros do after all! The important distinction is how that binary package was arrived at. If it's a mystery and the source isn't available then that's bad. If it's all in the open source repo and part of the Python package build and is completely reproducible then that's great.
GP's solution is the one that I (and I think most people) ultimately wind up using. But it's not a nice time in the usual "oh we'll just compile it" sense of a typical package.
flash-attn in particular has its build so badly misconfigured and is so heavy that it will lock up a modern Zen 5 machine with 128GB of DDR5 if you don't re-nice ninja (assuming of course that you remembered it just won't work without a pip-visible ninja). It can't build a wheel (at least not obviously) that will work correctly on Ampere and Hopper both, it incorrectly declares it's dependencies so it will demand torch even if torch is in your pyproject.toml and you end up breaking build isolation.
So now you've got your gigabytes of fragile wheel that won't run on half your cards, let's make a wheel registry. Oh, and machine learning everything needs it: half of diffusers crashes at runtime without it. Runtime.
The dirty little secret of these 50MM offers at AI companies is that way more people understand the math (which is actually pretty light compared to say graduate physics) than can build and run NVIDIA wheels at scale. The wizards who Zuckerberg will fellate are people who know some math and can run Torch on a mixed Hopper/Blackwell fleet.
And this (I think) is Astral's endgame. I think pyx is going to fix this at scale and they're going to abruptly become more troublesome to NVIDIA than George Hotz or GamersNexus.
Dumb question from an outsider - why do you think this is so bad? Is it because so much of the ML adjacent code is written by people with background in academia and data science instead of software engineering? Or is it just Python being bad at this?
1. If you want to advance the state of the art as quickly as possible (or have many, many experiments to run), being able to iterate quickly is the primary concern.
2. If you are publishing research, any time spent beyond what's necessary for the paper is a net loss, because you could be working on the next advancement instead of doing all the work of making the code more portable and reusable.
3. If you're trying to use that research in an internal effort, you'll take the next step to "make it work on my cloud", and any effort beyond that is also a net loss for your team.
4. If the amount of work necessary to prototype something that you can write a paper with is 1x, the amount of work necessary to scale that on one specific machine configuration is something like >= 10x, and the amount of work to make that a reusable library that can build and run anywhere is more like 100x.
So it really comes down to - who is going to do the majority of this work? How is it funded? How is it organized?
This can be compared to other human endeavours, too. Take the nuclear industry and its development as a parallel. The actual physics of nuclear fission is understood at this point and can be taught to lots of people. But to get from there to building a functional prototype reactor is a larger project (10x scale), and then scaling that to an entire powerplant complex that can be built
in a variety of physical locations and run safely for decades is again orders of magnitude larger.
TLDR: Broken builds are the default in everything, only exceptional effort and resources get you anything else, in Python, the people with those resources have unclear incentives for anything to improve.
I think it's a combination of historical factors and contemporary misaligned incentives both in the small and the large. There are also some technical reasons why Python is sort of an "attractive nuisance" for really problematic builds.
The easy one that shouldn't be too controversial is that it has a massive C/C++ (and increasingly Rust) native code library ecosystem. That's hard to do under the best of circumstances, but it's especially tough in Python (paradoxically because Python is so good at this: when wrapping the fast library that's proven is really easy you do it all the time). In the absence of really organized central planning and real "SAT Solver Class" package managers (like `uv`, not like `pip`), a mess is more or less just nature taking it's course. That's kinda how we got here (or how we got to 2016 maybe).
But lots of language ecosystems predate serious solvers and other modern versioning, why is Python such a conspicuous mess on this in 2025? How can friggin Javascript have it together about 100x better?
That's where the bad incentives kick in. In the small, there is a lingering prestige attached to "AI Researcher" that makes about zero sense in a world where we're tweaking the same dozen architectures and the whole game is scaling it, but that's the way the history went. So people who need it to work once to write a paper and then move on? `pip freeze` baby, works on my box. Docker amplifies this "socialize the costs" thing because now you can `pip freeze` your clanky shit, spin it up on 10k Hopper cards, and move on. So the highest paid, most regarded, most clout-having people don't directly experience the pain, it's an abstraction to them.
In the large? If this shit worked then (hopefully useful oversimplification alert) FLOPs would be FLOPs. The LAPACK primitives and even more modern GEMM instructions can be spelled some fast way on pretty much any vendor's stuff. NVIDIA is usually ahead a word-shrink or two, but ROCm in principle supports training at FP8 and on CDNA (expensive) cards it does, on RNDA (cheap) cards, it says it does on the label but crashes under load so you can't use it if your time is worth anything.
The big labs and FAANGs are the kind of dark horse here. In principle you'd assume Meta would want all their Torch code to run on AMD, but their incentives are complicated, they do a lot of really dumb shit that's presumably good for influential executives because it's bad for shareholders. It's also possible that they've just lost the ability to do that level of engineering, it's hard and can't be solved by numbers or money alone.
It's not a workaround; it's the most sane way of shipping such software. As long as the builds are reproducible there's nothing wrong with shipping binaries by default, especially when those binaries require non-trivial dependencies (the whole CUDA toolchain) to build.
There's a reason why even among the most diehard Linux users very few run Gentoo and compile their whole system from scratch.
I agree with you that binary distribution is a perfectly reasonable adjunct to source distribution and sometimes even the more sensible one (toolchain size, etc).
In this instance the build is way nastier than building the NVIDIA toolchain (which Nix can do with a single line of configuration in most cases), and the binary artifacts are almost as broken as the source artifact because of NVIDIA tensor core generation shenanigans.
The real answer here is to fucking fork flash-attn and fix it. And it's on my list, but I'm working my way down the major C++ packages that all that stuff links to first. `libmodern-cpp` should be ready for GitHub in two or three months. `hypermodern-ai` is still mostly a domain name and some scripts, but they're the scripts I use in production, so it's coming.
I thought about fixing Flash Attention too so that I don't have to recompile it every time I update Python or pytorch (it's the only special snowflake dependency that I need to manually handle), but at the end of the day it's not that much of a pain to justify the time investment.
If I'm going to invest time here then I'd rather just write my own attention kernels and also do other things which Flash Attention currently doesn't do (8-bit and 4-bit attention variants similar to Sage Attention, and focus on supporting/optimizing primarily for GeForce and RTX Pro GPUs instead of datacenter GPUs which are unobtanium for normal people).
I usually think the same way, and I bet a lot of people do which is why its still broken. But I've finally decided it's never going away completely and it's time to just fix it.
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.
Developing a good and configurable formatter is a project almost as complex as uv's main focus, managing packages. As such it will divert time and attention from its main purpose and the outcome is questionable, considering how many bad formatters are out there. For example the "opinionated" black is terrible and has no awareness of semantics.
We already develop a formatter: Ruff (https://github.com/astral-sh/ruff). Ruff and uv are built by the same team. `uv format` is just an optional front-end to `ruff format`.
But, for example, my project already uses Ruff, and I have to worry about having a "managed" extra copy of Ruff that subtly alters the normal functioning both of "uv tool run" and of ruff itself.
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.
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?)
Not really. If you know about uv, you know how to use "uv tool run", so you know how to use any formatter of your choice (which you can find easily on Google, arguably easier than reading the documentation and learning about uv format).
Well, it is arguably worse to run an unknown, not version pinned, unconfigured formatter over your code and expect it to improve things, unless the code is an utter catastrophe in terms of formatting.
_You_ may find it irrelevant, but speak for yourself. I don't want dependencies, that are not version-pinned and checksummed running over my code. It is certainly not irrelevant to me.
I find this hard to believe since black doesn't even have the same rules as black's next version and I never changed version without something being reformatted.
Also because of fun, if you reformat again with the older version it won't go back to as it was before :)
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...
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.
What's wrong with the approach is that it goes against basic principles of the Python ecosystem. Python has always followed the policy of standardising mechanisms and allowing implementations to develop and peacefully coexist. The Python way fosters diversity of implementations. Note that uv itself would not be a reasonable project if not for Python's approach to diverse tooling.
You cite good examples where other languages have chosen to standardise tooling. We can discuss the pros and cons of that choice. But it is a choice, and Python already made a different choice.
All of our tools can be used independently and in coexistence with other tools. You can use `uv` with other build backends; you can use `virtualenv` to create your virtual environments, and `uv pip` to install into them; you can use `ruff` as a linter and `black` as a formatter, or `ruff` for both, or whatever. Here, similarly, you can use `uv` with `ruff`, or bring your own formatter. It's intentional for us that you can use the pieces that you want, and interoperate with other tools. But it's also intentional that we want using our tools _together_ to be a great experience. I think we can achieve both of these things. Or, at least, we're going to try.
Apparently this is itself a self-referential joke because of the two ways the dashes are spaced for that sentence and then again differently a third time at the end ….
uv exists because Python's default packaging situation is a mess. There was supposed to be one way to do it, pip, but then it became pip + venv because it's too unreliable otherwise, but that's still bad.
what if somebody happens to not like the Basic Principles of the Python Ecosystem? most languages do quite well with a single package manager, it's getting harder to argue that Python's need to introduce a new one every year is actually a good thing
"The basic principles of the Python ecosystem" are a dumpster fire to anyone who isn't already desensitized to the situation. Just like 'uv' as a whole, this seems like a meaningful step towards making Python a little less terrible to actually use, and should be applauded.
One thing I wonder about is what happens in pyproject? Do you use tool.ruff/tool.ruff.format or tool.uv.format or what? Are people who only know "uv format" supposed to understand that part? Does ruff start honoring tool.uv.format? Which have priority over which in search. Does it behave differently when you run uv format vs ruff format? etc
What is “third party” here? Pip and UV are both external dependencies used to install other external dependencies. What makes them different from each other, or from the other dependencies you are using them to install?
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.
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.
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.
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.
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.
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.
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.
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.
I switched to ruff for the great linting. When they introduced a formatter, I gave it a try and:
- got similar results
- but runs faster
- I could delete one dev dependency
Given black's motto (any color as long as it's black), now I pick ruff and go with whatever formatting it produces.
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.
Thanks for pointing that out. This is news to me. uv has been on my radar for a while and was considering switching to it as a better dependency manager. I didn't realise that it had ambitions beyond being "a better pip." At face value this is a real turn-off. Definitely violates the "do one thing and do it well" principle and puts it squarely in the "does complicated things that I want to avoid" (like poetry) category.
> "uv build" makes .wheel files, so it is analogous to "cargo publish" (which makes .crate files) as opposed to "cargo build"
This isn't exactly right: `uv build` executes a PEP 517[1] build backend interface, which turns a Python source tree into installable distributions. Those distributions can be sdists or wheels; in this sense, it's closer to `cargo build` than `cargo publish`.
The closer analogy for `cargo publish` would be `uv publish`, which also already exists[2]: that command takes an installable distribution and uploads it to an index.
TL;DR: `uv build` is a proxy for a build system, because that's how distribution construction is standardized in Python. I would not say it's analogous to `cargo publish`, since it's responsible for builds, not publishes.
cargo publish bundles your source files into a format (.crate) that can be distributed to other developers. This includes instructions for actually building the project at a later time. This is analagous to 'uv build' making an .sdist file.
I guess it gets more complicated with .whl since those can contain build artifacts as well and not just build instructions.
It's true that 'cargo publish' can also upload your .crate files to a remote repository, while uv breaks that functionality out into a separate command called 'uv publish' but I think that's neither here nor there on the difference between bundling the source and building the source.
I would say that `cargo publish` uploading a package to a remote index (like crates.io) is its primary purpose. I've been writing Rust for about 7 years now and I don't think I've ever seen someone use it primarily to generate a `.crate` file without uploading it somewhere.
This is starting to sound like uv is a trojan horse that was introduced as a package manager and is now seeking to replace the diverse python ecosystem with a totalizing approach that is anathema to the the python way (standardize protocols, accommodate diverse implementations).
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.
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.
The native integration offers persistent configuration, caching, and project-aware behavior that uvx (which just creates an ephemeral venv) doesn't provide.
I would imagine that a person who is seriously concerned about any of that would just install a standalone version of ruff. Given the existence of uvx, this addition seems like feature creep to me.
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.
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.
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.
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.
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.
> 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.
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.
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.
Meanwhile, they provide identical functionality. (`Under the hood, it calls Ruff’s formatter to automatically style your code according to consistent standards.`)
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 :)
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
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?
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.
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:
Is it just me, or do other people also have the impression that a lot of sock puppets are advertising for the Astral company on the internet?
That said, I may not have installed super complex packages, but for years now I have never ever experienced one situation (on Windows, ok) where pip did not just work. For me, pip is the way.
I also have the Python folder be a Git repo, and every `pip install` is a commit, and every project is a branch. Why so difficult?
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.
Not all devs have very deep knowledge of the ecosystem, some will get to use a tool only if it's part of the default set of tools they're provided.
Plus, it saves on memorizing a name if you only use python once in a long while.
There just isn't much of a reason not to.
I landed in python last year, the pre uv time for me. The language itself is fine, but the project organization sucked. What kind of folder structure to choose? Do I use pip, env, pipenv, poetry? How to format, and with which settings? I've read tens of blog post, all giving different choices, all equally reasonable, all having some downsides.
The great thing about uv is not that their choices are best, it's that the choices have been made, the gordian knots cut. There is a good enough standard to build upon. Future python projects will look a lot more like each other, and less time will be wasted on organizational minutiae.
As someone who has worked on package managers quite a bit in the past, and for that examined prior art across package managers, that's because Cargo is doing things very well on almost all fronts. Partially because of their RFC process and partially because they have the luxury of being a "newer" package manager that doesn't have to live with ecosystem baggage going many decades back.
There are/were definitely some weaker spots with Cargo (e.g. private registry support was meh for some time), but if one were tasked to build a package manager and were only allowed to pick a single one to take inspration from, Cargo is definitely the way to go.
Anyone from uv reading this?
please scrap this thing, there is a separate formatter ruff that anyone ll use if they want a formatter. please do not complicate stuff. ruff ll come with its own configuration. this will have its own config at some point. potential rule clashes, ignore plugins. please do not go in this direction
A clean alternative: automatically adding ruff as a tool when creating a new pyproject.toml file, with a command line flag to opt out for the minority who know they don't intend to use ruff. For the majority of users, simplicity is worth an accidental download.
I recognize that uv is very popular but it still feels faddish.
I don't want my package manager to format anything.
I don't want my package manager to lint anything.
I don't want my package manager to `run` anything.
I don't want my package manager to even manage environments (yes yes this one is a bit extreme).
I want to have single purpose tools that work together well.
This way I can have a flexible, composable toolchain that can both adapt to me and my specific project.
For example, I like conda, pip, ruff, mypy, flake8. Someone else might like venv, pip, black, pyright, flake8.
This is the heart of the Unix Philosophy and I feel like it's a philosophy each software community has to reject, suffer due to that rejection, and re-adopt on a regular basis. I'd rather we skip the suffering bit.
It's a minor issues in teams where people use inconsistent formatting. This causes needless complications when merging code and additional work related to resolving conflicts that shouldn't exist to begin with.
Some languages (Go, Rust) have essentially solved this issue to the point where blindly running the formatters these languages have solves the problem and is uncontroversial.
Sadly, the language of choice for me (Kotlin) has a big unaddressed problem here where what the IDE does for formatting and what independent formatting tools do are two things that are hard to align for mostly the historical reasons that what the IDE does is fragmented over different bits of code that don't listen to the same configuration. There is a lot of variation in preferences for indentation, where to put new lines, line length, what order to put imports in, which imports to use wildcards for (if any at all), etc. Particularly imports are a problem because the bit of code that organizes imports is separate from the bit of code that formats code in the IDE.
The common solution of using IDE plugins to work around this is a bit of a kludge. The proper solution would be a more sane way to just make the IDE externally configurable so that build tools can make the IDE do exactly the same as what they do without requiring users to manually configure their IDEs just right by installing plugins or fiddling with configuration. This stuff should not be user controllable if there is a build file that defines the proper formatting.
Coding agents actually add to this problem. Because getting those to stick to formatting conventions is tricky. Unless you have tools that just fix that properly.
So good change in uv and probably something I'd be using on my next python project (I do those once in a while).
That's exactly what I mean by kludge. And this attitude is exactly the problem and reason why most languages continue to do the wrong thing here.
Your solution requires user discipline and fiddling with things that should just work right without fiddling. And it needs to happen on every development environment. You can't really enforce it except via annoying additional kludges in the form of failing builds.
I've never been on a team where this was done right. I've been on plenty of teams with convoluted half enforced formatting rules (and thousands of violations).
I know how to fix it for my own code. But being able to force everyone I have to work with to do the same thing over and over again is the problem that needs solving. Everybody just shrugs it off and does nothing about it. What are you going to do. It's always been this miserable this way. Industry wide apathy on this topic.
That's why I appreciate what Google did with Go here so much. Not a fan of the language necessarily. But they did the right thing with making code formatting not optional and a compile error to skip.
Stuff like this should not be a debate or discussion or a follow this 20 step process to setup your work environment properly but just something that works right (for fuzzy definitions of right) as specified by the build file in the code repository.
It's a minor annoyance that I wish Jetbrains would just take more serious.
DevOps are the disciple that tames the developer team malpractices, it doesn't stop at formating, static analysis, misbehaved dependencies taken directly out of Internet without IT approval, no proper security workflows, there is no need for user disciple with manual steps.
I hope for uv's sake, that the formatting is always optional and that it is not "opinionated" (read: half asses and no way to configure it), but configurable. And if we get into that, well, it's a whole different tool, that they are trying to put into uv. Seems like a bad idea.
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.
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.
Thank you for writing software for all of us Python day-jobbers who wish we were writing Rust instead.
Never seen someone put my feeling so succinctly
You can advocate for using Rust at work.
If you're writing microservices, the Rust ecosystem sells itself at this point.
What Rust has over other languages that makes it better for writing microservices?
API-first or API-only backends are a sweet spot for today's Rust, IMO, and its resource footprint, reduced maintenance long-tail, and performance properties are all super competitive. It's especially hard to find another language that can compete with Rust on all three of those at once.
>reduced maintenance long-tail
I'd like to hear more about that. I'm also curious what makes Rust particularly suited to "API-first" backends. My understanding of the language is that it's concurrency primitives are excellent but difficult to learn and it's gc-less runtime.
> it's concurrency primitives are excellent but difficult to learn
They're actually incredibly easy to learn if your software paradigm is the request-response flow.
The borrow checker might kill your productivity if you're writing large, connected, multi-threaded data structures, but that simply isn't the nature of 90% of services.
If you want to keep around global state (db connectors, in-memory caches, etc.) Arc<Mutex<T>> is a simple recipe that works for most shared objects. It's dead simple.
You can think of Rust with Axum/Actix as a drop-in replacement for Go or Python/Flask. With the added benefits of (1) no GC / bare metal performance, (2) much lower defect rate as a consequence of the language ergonomics, (3) run it and forget it - no GC tuning, very simple scaling.
Rust has effectively made writing with the performance of C++ feel like writing Ruby, but with unparalleled low defect rates and safety on account of the type system.
>Rust has effectively made writing with the performance of C++ feel like writing Ruby, but with unparalleled low defect rates and safety on account of the type system.
This is a little overblown.. speaking VERY HAND-WAVILY, sea_orm < active record by a factor of about 10x more mental overhead but is at least that much more performant...
but yea, vibe-coding rust micro services is pretty amazing lately, almost no interactions with borrow checker, and I'm even using cucumber specs...
You're right on that front.
I currently wouldn't recommend any Rust ORM, Diesel included. They're just not quite ready for prime time.
If you're not one to shy away from raw SQL, then SQLx is rock-solid. I actually prefer it over ORMs in general. It's type-checked at runtime or compile time against your schema, no matter how complex the query gets. It manages to do this with an incredibly simple design.
It's like an even nicer version of Java's popular jOOQ framework, which I always felt was incredibly ugly.
SQLx might be my very favorite SQL library of any language.
I will give it another look, thanks!
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).
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.)
> (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.
Would you ever consider bundling ruff binaries with uv releases similar to uvx and uvw? It would benefit offline users and keep compatible uv/ruff versions in sync.
Perhaps even better… cargo-like commands such as uv check, uv doc, and uv test could subsume ruff, ty, and other tools that we haven’t seen yet ;)
A pyup command that installs python-build-standalone, uv, python docs, etc. would be totally clutch, as would standalone installers [0] that bundle it all together.
[0] https://forge.rust-lang.org/infra/other-installation-methods...
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.
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.
[dead]
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?)
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!
> Is `uv format` supposed to be an alias for `ruff check`?
I'd imagine not, since `ruff format` and `ruff check` are separate things too.
That makes some more sense. I think I just misunderstood what Charlie was saying above.
But I'll also add another suggestion/ask. I think this could be improved
I think just a little more can go a long way. When --help is the docs instead of man I think there needs to be a bit more description. Just something like this tells users a lot more I think man/help pages are underappreciated. I know I'm not the only one that discovers new capabilities by reading them. Or even the double tab because I can't remember the flag name but see something I didn't notice before. Or maybe I did notice before but since the tool was new I focused on main features first. Having the ability to read enough information to figure out what these things do then and there really speeds up usage. When the help lines don't say much I often never explore them (unless there's some gut feeling). I know the browser exists, but when I'm using the tool I'm not in the browser.> 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.
ruff is not compiled into uv; it's bootstrapped from an independent build, much like how `cargo fmt` is bootstrapped from a separate toolchain component (rustfmt). You can see how that works in the PR[1]. Importantly, that means that you don't experience any build-, install-, or run-time burden if you don't use this subcommand.
[1]: https://github.com/astral-sh/uv/pull/15017
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`
You can always use `uvx ruff check` or `uv tool run ruff check`. Though honestly I find just running `ruff check` much easier.
uv ruffy sounds funny
Does it have the capability to use a different formatter than ruff?
This is about providing an opinionated default. uv will still support installing and runing any formater as before.
They are mimicking Rust's cargo, which has `cargo fmt`
> They are mimicking Rust's cargo
Cargo cargo cult?
It's not a cargo cult if it actually works.
Also `go fmt` and `dart format`.
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.
cargo has an external subcommand system, but it also has "blessed" (my word choice) external subcommands that are typically bootstrapped via Rust toolchain components. This makes them pretty analogous to what uv does here with `uv format`, in my opinion.
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.
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.
GP should have written project manager not package.
Think npm / go / cargo, not apt/yum/pip.
Doesn't make it less feature creep.
One of the maintainers said in another comment that it will download the formatter (ruff) and it is not embedded. So if you don't use that feature you won't even notice: https://news.ycombinator.com/item?id=44978660
I’m sure you’re a old man on the verge of death who loves yelling at clouds but enforcement and application of consistent code formatting has been considered a basic part of project management for a while now. Recent langage provide it as part of core project management tooling.
Given uv is openly strongly inspired by cargo and astral also has tooling for code formatting, the integration was never a question of “if”.
I remember how in a previous job the code formatter cost me time and time again. I already intentionally format my code as it makes sense and with the goal of improving readability. Then the damn auto formatter comes along and destroys this, by splitting a log call over 5 lines, because it has seen, that the log call is longer than 80 characters. Thank you for wasting 5 LoC of screen space for something that is a sidenote basically. That'll surely improve readability. So what do people do? They increase line length to 200 characters, to avoid this shit happening. Only that now it does no longer break long lines that should be broken. Unless I added trailing comma everywhere, wasting more time to make the formatter behave properly.
I am not against auto formatters in general, but they need to be flexible and semantically aware. A log call is not the same as other calls in significance. If the auto formatter is too silly to do that, then I prefer no auto formatter at all and keep my code well formatted myself, which I do anyway while I am writing the code. I do it for my own sake and for anyone who comes along later. My formatting is already pretty much standard.
It’s not a package manager. It’s a project manager.
Doing a lot of Rust, there is one huge benefit of having cargo handle rustfmt: it knows the fileset you're talking about. It will not blindly format all rust files in the cwd, rather the "current" crate (current having the same definition as cargo!).
Translating this to uv, this will streamline having multiple python packages in the same directory/git repo, and leave e.g. vendored dependencies alone.
Also, since their goal really is "making cargo for python", it will likely support package-scoped ruff config files, instead of begin file- or directory-based.
i think it's good to let them experiment! cargo (and go?) offers this already, so why not.
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.
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.
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 ).
All actions listed in your first paragraph, except for installing specific Python versions, are actions related to the area of packaging. Doing it in one tool is completely sensible. I'm not a fan of uv managing Pythons, but I guess that ship has sailed.
But formatting code is a completely new area that does not fit uv.
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?
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
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.
They are not forcing anything on anyone. You can decide to never run `uv format` and ruff won’t even be installed.
You can use uv without ruff. You can use ruff without uv. You can invoke ruff yourself if that’s what you want. Or use any other formatter.
I don’t think I understand what your complaint is.
Other people having an opinion and creating their own software project to implement it is not “forcing” anyone to do anything.
The inverse would be no one is allowed to create any projects that you don’t personally agree with.
Nobody is forcing you to use anything. Feel free to ignore it and use whatever flavor you like.
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?
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".
How is "uv format" a better name, or more "abstract", etc. etc., than "ruff check"? Why is it easier to think of my formatter and package manager (or whatever other pieces) as being conceptually the same tool, given that they are doing clearly different, independent and unrelated things?
And why is any of this relevant to first-time Python learners? (It's already a lot to ask that they have to understand version control at the same time that they're learning specific language syntax along with the general concept of a programming language....)
It’s an abstraction because it literally hides knowledge in service of presenting a more a more cohesive API to the human.
It requires less knowledge at the front end, which is when people are being bombarded with a ton of new things to learn.
Learners don’t have to even know what ruff is immediately. They just know that when they add “format” to the command they already know, uv, their code is formatted. At some later date when they know Python better and have more opinions, they can look into how and why that’s accomplished, but until then they can focus on learning Python.
uv isn’t a package manager only, its best thought of as a project manager, just like go or cargo. Its “one thing” is managing your Python project.
Would Linux similarly be better if we wrote e.g. "cu list" instead of "ls", "cu change" instead of "cd", etc.? (The "cu" stands for "coreutils", of course.) Because it seems to me like the same arguments apply. I was already thinking of uv as a "project manager" and I understand that intended scope, and even respect the undertaking. My point is that I don't believe that labeling all the tasks under that scope like this actually improves the UX.
Maybe I'm wrong about that. But I don't know that it can actually be A/B tested fairly, given network effects (people teaching each other or proselytizing to each other about the new way).
I don't think Linux would be better with a `cu` prefix for coreutils, but I do think git would be worse without a `git` prefix. I think it's ultimately a question of user expectations, and I think user expectations around packaging tooling in particular have shifted towards the Go and Rust styles of providing a "namespace" tool that provides a single verb-style interface for developer actions.
the meaning of the word "ruff" has nothing to do with formatting. Therefore it's harder to remember than "format". if they could just call the formatter "format", that would be best, but obviously that name is too overloaded. So they namespace it under a tool people already know, "uv".
Let's imagine you're learning a new language, which has tools with names that I just made up. Which has a clearer pattern to you?
Or Clearly, the first is easier to remember. The benefit of namespacing is that you only need to remember one weird/unique name, and then everything under that can have normal names. If you don't have namespacing, you need weird/unique names for every different tool.Well for one thing separate commands that are as good as what uv does don’t exist
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?
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]
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
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.
> 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.
This is a self-inflicted wound, since flash attention insist on building a native C++ extension which is completely unnecessary in this case.
What you can do is the following:
1) Compile your CUDA kernels offline. 2) Include those compiled kernels in a package you push to pypi. 3) Call into the kernels with pure Python, without going through a C++ extension.
I do this for the CUDA kernels I maintain and it works great.
Flash attention currently publishes 48 (!) different packages[1], for different combinations of pytorch and C++ ABI. With this approach it would have to only publish one, and it would work for every combination of Python and pytorch.
[1] - https://github.com/Dao-AILab/flash-attention/releases/tag/v2...
While shipping binary kernels may be a workaround for some users, it goes against what many people would consider "good etiquette" for various valid reasons, such as hackability, security, or providing free (as in liberty) software.
Shipping binary artifacts isn't inherently a bad thing - that's what (most) Linux Distros do after all! The important distinction is how that binary package was arrived at. If it's a mystery and the source isn't available then that's bad. If it's all in the open source repo and part of the Python package build and is completely reproducible then that's great.
GP's solution is the one that I (and I think most people) ultimately wind up using. But it's not a nice time in the usual "oh we'll just compile it" sense of a typical package.
flash-attn in particular has its build so badly misconfigured and is so heavy that it will lock up a modern Zen 5 machine with 128GB of DDR5 if you don't re-nice ninja (assuming of course that you remembered it just won't work without a pip-visible ninja). It can't build a wheel (at least not obviously) that will work correctly on Ampere and Hopper both, it incorrectly declares it's dependencies so it will demand torch even if torch is in your pyproject.toml and you end up breaking build isolation.
So now you've got your gigabytes of fragile wheel that won't run on half your cards, let's make a wheel registry. Oh, and machine learning everything needs it: half of diffusers crashes at runtime without it. Runtime.
The dirty little secret of these 50MM offers at AI companies is that way more people understand the math (which is actually pretty light compared to say graduate physics) than can build and run NVIDIA wheels at scale. The wizards who Zuckerberg will fellate are people who know some math and can run Torch on a mixed Hopper/Blackwell fleet.
And this (I think) is Astral's endgame. I think pyx is going to fix this at scale and they're going to abruptly become more troublesome to NVIDIA than George Hotz or GamersNexus.
Dumb question from an outsider - why do you think this is so bad? Is it because so much of the ML adjacent code is written by people with background in academia and data science instead of software engineering? Or is it just Python being bad at this?
1. If you want to advance the state of the art as quickly as possible (or have many, many experiments to run), being able to iterate quickly is the primary concern.
2. If you are publishing research, any time spent beyond what's necessary for the paper is a net loss, because you could be working on the next advancement instead of doing all the work of making the code more portable and reusable.
3. If you're trying to use that research in an internal effort, you'll take the next step to "make it work on my cloud", and any effort beyond that is also a net loss for your team.
4. If the amount of work necessary to prototype something that you can write a paper with is 1x, the amount of work necessary to scale that on one specific machine configuration is something like >= 10x, and the amount of work to make that a reusable library that can build and run anywhere is more like 100x.
So it really comes down to - who is going to do the majority of this work? How is it funded? How is it organized?
This can be compared to other human endeavours, too. Take the nuclear industry and its development as a parallel. The actual physics of nuclear fission is understood at this point and can be taught to lots of people. But to get from there to building a functional prototype reactor is a larger project (10x scale), and then scaling that to an entire powerplant complex that can be built in a variety of physical locations and run safely for decades is again orders of magnitude larger.
TLDR: Broken builds are the default in everything, only exceptional effort and resources get you anything else, in Python, the people with those resources have unclear incentives for anything to improve.
I think it's a combination of historical factors and contemporary misaligned incentives both in the small and the large. There are also some technical reasons why Python is sort of an "attractive nuisance" for really problematic builds.
The easy one that shouldn't be too controversial is that it has a massive C/C++ (and increasingly Rust) native code library ecosystem. That's hard to do under the best of circumstances, but it's especially tough in Python (paradoxically because Python is so good at this: when wrapping the fast library that's proven is really easy you do it all the time). In the absence of really organized central planning and real "SAT Solver Class" package managers (like `uv`, not like `pip`), a mess is more or less just nature taking it's course. That's kinda how we got here (or how we got to 2016 maybe).
But lots of language ecosystems predate serious solvers and other modern versioning, why is Python such a conspicuous mess on this in 2025? How can friggin Javascript have it together about 100x better?
That's where the bad incentives kick in. In the small, there is a lingering prestige attached to "AI Researcher" that makes about zero sense in a world where we're tweaking the same dozen architectures and the whole game is scaling it, but that's the way the history went. So people who need it to work once to write a paper and then move on? `pip freeze` baby, works on my box. Docker amplifies this "socialize the costs" thing because now you can `pip freeze` your clanky shit, spin it up on 10k Hopper cards, and move on. So the highest paid, most regarded, most clout-having people don't directly experience the pain, it's an abstraction to them.
In the large? If this shit worked then (hopefully useful oversimplification alert) FLOPs would be FLOPs. The LAPACK primitives and even more modern GEMM instructions can be spelled some fast way on pretty much any vendor's stuff. NVIDIA is usually ahead a word-shrink or two, but ROCm in principle supports training at FP8 and on CDNA (expensive) cards it does, on RNDA (cheap) cards, it says it does on the label but crashes under load so you can't use it if your time is worth anything.
The big labs and FAANGs are the kind of dark horse here. In principle you'd assume Meta would want all their Torch code to run on AMD, but their incentives are complicated, they do a lot of really dumb shit that's presumably good for influential executives because it's bad for shareholders. It's also possible that they've just lost the ability to do that level of engineering, it's hard and can't be solved by numbers or money alone.
It's not a workaround; it's the most sane way of shipping such software. As long as the builds are reproducible there's nothing wrong with shipping binaries by default, especially when those binaries require non-trivial dependencies (the whole CUDA toolchain) to build.
There's a reason why even among the most diehard Linux users very few run Gentoo and compile their whole system from scratch.
I agree with you that binary distribution is a perfectly reasonable adjunct to source distribution and sometimes even the more sensible one (toolchain size, etc).
In this instance the build is way nastier than building the NVIDIA toolchain (which Nix can do with a single line of configuration in most cases), and the binary artifacts are almost as broken as the source artifact because of NVIDIA tensor core generation shenanigans.
The real answer here is to fucking fork flash-attn and fix it. And it's on my list, but I'm working my way down the major C++ packages that all that stuff links to first. `libmodern-cpp` should be ready for GitHub in two or three months. `hypermodern-ai` is still mostly a domain name and some scripts, but they're the scripts I use in production, so it's coming.
I thought about fixing Flash Attention too so that I don't have to recompile it every time I update Python or pytorch (it's the only special snowflake dependency that I need to manually handle), but at the end of the day it's not that much of a pain to justify the time investment.
If I'm going to invest time here then I'd rather just write my own attention kernels and also do other things which Flash Attention currently doesn't do (8-bit and 4-bit attention variants similar to Sage Attention, and focus on supporting/optimizing primarily for GeForce and RTX Pro GPUs instead of datacenter GPUs which are unobtanium for normal people).
I usually think the same way, and I bet a lot of people do which is why its still broken. But I've finally decided it's never going away completely and it's time to just fix it.
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.
> I don’t understand why adding a subcommand to uv is being considered bloat.
It's simple:
- Everything I use and I see: good
- Everything I don't use and I see: bloat
- Everything I use and I don't see: good
- Everything I think I don't use and I don't see: Java
Developing a good and configurable formatter is a project almost as complex as uv's main focus, managing packages. As such it will divert time and attention from its main purpose and the outcome is questionable, considering how many bad formatters are out there. For example the "opinionated" black is terrible and has no awareness of semantics.
We already develop a formatter: Ruff (https://github.com/astral-sh/ruff). Ruff and uv are built by the same team. `uv format` is just an optional front-end to `ruff format`.
The formatter already exists, my understanding is that this is merely an alias for "uvx ruff"...
When talking about uv, this comes across similar to saying that "the 'make' command has too many targets".
Are they baked into the main executable or are they separate binaries (a la apt, cargo, etc)?
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.
But, for example, my project already uses Ruff, and I have to worry about having a "managed" extra copy of Ruff that subtly alters the normal functioning both of "uv tool run" and of ruff itself.
It's intentionally distinct from the `uv tool` interface — it won't change `ruff` or `uv tool run` behaviors.
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.
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?)
But you have to know about ruff. I didn't, but I did know about uv.
Not really. If you know about uv, you know how to use "uv tool run", so you know how to use any formatter of your choice (which you can find easily on Google, arguably easier than reading the documentation and learning about uv format).
He said "you have to know about ruff". You're not really refuting that by saying "no you don't, you can just google it".
But I don’t know what the formatter of choice is. Nor do I care what it is. I just want to format my code
Well, it is arguably worse to run an unknown, not version pinned, unconfigured formatter over your code and expect it to improve things, unless the code is an utter catastrophe in terms of formatting.
It is completely irrelevant.
You’re offloading responsibility to uv devs in this case.
_You_ may find it irrelevant, but speak for yourself. I don't want dependencies, that are not version-pinned and checksummed running over my code. It is certainly not irrelevant to me.
That’s for uv for decide. If you don’t like what it does - don’t use uv.
Let me rewrite your comment a little bit to make clearer what you’re saying.
> I don’t think additional complexity counts as being worse.
Yes, it does.
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
fwiw `ruff format` includes nearly all the black rules by default / supports a superset of black's options https://astral.sh/blog/the-ruff-formatter
Ruff pretty much follows the same rules as black, and can be made identical with some options tweaking.
So when I moved several projects from black to ruff, there were no changes made to the code.
That wasn't my experience. I tried it on a large project and about 1% of lines were changed. Not a big deal IMO but enough for naysayers to complain.
I find this hard to believe since black doesn't even have the same rules as black's next version and I never changed version without something being reformatted.
Also because of fun, if you reformat again with the older version it won't go back to as it was before :)
Thanks for the downvotes. Really shows that you have no familiarity with black.
Strong agree, they can even make the formatter configurable in pyproject if you want to use something else.
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...
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.
What's wrong with the approach is that it goes against basic principles of the Python ecosystem. Python has always followed the policy of standardising mechanisms and allowing implementations to develop and peacefully coexist. The Python way fosters diversity of implementations. Note that uv itself would not be a reasonable project if not for Python's approach to diverse tooling.
You cite good examples where other languages have chosen to standardise tooling. We can discuss the pros and cons of that choice. But it is a choice, and Python already made a different choice.
All of our tools can be used independently and in coexistence with other tools. You can use `uv` with other build backends; you can use `virtualenv` to create your virtual environments, and `uv pip` to install into them; you can use `ruff` as a linter and `black` as a formatter, or `ruff` for both, or whatever. Here, similarly, you can use `uv` with `ruff`, or bring your own formatter. It's intentional for us that you can use the pieces that you want, and interoperate with other tools. But it's also intentional that we want using our tools _together_ to be a great experience. I think we can achieve both of these things. Or, at least, we're going to try.
I’m not sure I agree with this. If anything, a diversity of implementations coexisting is against the basic principles of Python.
> There should be one-- and preferably only one --obvious way to do it.
- PEP20 - The Zen of Python
Apparently this is itself a self-referential joke because of the two ways the dashes are spaced for that sentence and then again differently a third time at the end ….
Yet python has two ways of writing string literals (single quote and double quote)
uv exists because Python's default packaging situation is a mess. There was supposed to be one way to do it, pip, but then it became pip + venv because it's too unreliable otherwise, but that's still bad.
You’re free to build your own Rube Goldberg machine, some of us just want to use well crafted tools and be done with it.
what if somebody happens to not like the Basic Principles of the Python Ecosystem? most languages do quite well with a single package manager, it's getting harder to argue that Python's need to introduce a new one every year is actually a good thing
But astral is a startup, they don't really want to coexist I guess.
A VC-funded startup at that. I'm wondering what will happen when the enshittification phase comes.
I don't understand why you are getting downvoted.
"The basic principles of the Python ecosystem" are a dumpster fire to anyone who isn't already desensitized to the situation. Just like 'uv' as a whole, this seems like a meaningful step towards making Python a little less terrible to actually use, and should be applauded.
One thing I wonder about is what happens in pyproject? Do you use tool.ruff/tool.ruff.format or tool.uv.format or what? Are people who only know "uv format" supposed to understand that part? Does ruff start honoring tool.uv.format? Which have priority over which in search. Does it behave differently when you run uv format vs ruff format? etc
What is your first choice?
Pip, because it introduces no third-party software. This is critical in regulated industries.
Oh boy, you're gonna have a really bad day when you figure out what "pip install" does.
What is “third party” here? Pip and UV are both external dependencies used to install other external dependencies. What makes them different from each other, or from the other dependencies you are using them to install?
It ships with your certified Linux distro. Period.
Ok, so why not just use pip to install uv?
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.
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.
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.
ty is already in the same repo as ruff, so integrating seems likely
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.
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.
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.
`uv format` is just a front-end for `ruff format`. It isn't introducing a new formatter to the ecosystem or anything like that.
You realize this is just a shortcut for one of those "time-tested" options, right? ruff format is already widely used.
But why bundle? It makes zero design sense to me.
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.
I'm not clear on this, but does it not also setup a backward dependency between the new project and uv?
Oh no I would hate to have to depend on my package manager and build system
When is UVA going to start handling email?
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.
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.
This approach is “violent”?
Foot massage and blowjob over coffee?
Do you even read you write? Work is about efficiency, not catering to every special snowflake.
Love this! I would name it `uv fmt` and add `uv vet` to the roadmap too
I use black and I like it. Where does ruff differ in terms of formatting?
It’s mostly similar, just a bit more consistent: https://docs.astral.sh/ruff/formatter/black/
and speed, it's way way faster
I switched to ruff for the great linting. When they introduced a formatter, I gave it a try and: - got similar results - but runs faster - I could delete one dev dependency
Given black's motto (any color as long as it's black), now I pick ruff and go with whatever formatting it produces.
Why does a package manager need a formatter at all?
Is cargo just a package manager? Go?
Careful, we're going to end up with some integrated development environment, that has all these things working nicely together!
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.
I don't know much about go.
uv is also a package manager and a build system.
https://docs.astral.sh/uv/concepts/build-backend/
Thanks for pointing that out. This is news to me. uv has been on my radar for a while and was considering switching to it as a better dependency manager. I didn't realise that it had ambitions beyond being "a better pip." At face value this is a real turn-off. Definitely violates the "do one thing and do it well" principle and puts it squarely in the "does complicated things that I want to avoid" (like poetry) category.
It gets difficult when you compare scripting languages to natively compiled languages, since some of the terminology is overloaded.
"uv build" makes .wheel files, so it is analogous to "cargo publish" (which makes .crate files) as opposed to "cargo build"
I would call this a packaging tool as opposed to a build system.
> "uv build" makes .wheel files, so it is analogous to "cargo publish" (which makes .crate files) as opposed to "cargo build"
This isn't exactly right: `uv build` executes a PEP 517[1] build backend interface, which turns a Python source tree into installable distributions. Those distributions can be sdists or wheels; in this sense, it's closer to `cargo build` than `cargo publish`.
The closer analogy for `cargo publish` would be `uv publish`, which also already exists[2]: that command takes an installable distribution and uploads it to an index.
TL;DR: `uv build` is a proxy for a build system, because that's how distribution construction is standardized in Python. I would not say it's analogous to `cargo publish`, since it's responsible for builds, not publishes.
[1]: https://peps.python.org/pep-0517/
[2]: https://docs.astral.sh/uv/guides/package/#publishing-your-pa...
cargo publish bundles your source files into a format (.crate) that can be distributed to other developers. This includes instructions for actually building the project at a later time. This is analagous to 'uv build' making an .sdist file.
I guess it gets more complicated with .whl since those can contain build artifacts as well and not just build instructions.
It's true that 'cargo publish' can also upload your .crate files to a remote repository, while uv breaks that functionality out into a separate command called 'uv publish' but I think that's neither here nor there on the difference between bundling the source and building the source.
I would say that `cargo publish` uploading a package to a remote index (like crates.io) is its primary purpose. I've been writing Rust for about 7 years now and I don't think I've ever seen someone use it primarily to generate a `.crate` file without uploading it somewhere.
This is starting to sound like uv is a trojan horse that was introduced as a package manager and is now seeking to replace the diverse python ecosystem with a totalizing approach that is anathema to the the python way (standardize protocols, accommodate diverse implementations).
Good. The state of affairs today is awful - what happened to "There should be one-- and preferably only one --obvious way to do it"?
They've been very outspoken about the intentions of uv being a similar tool to cargo from the start.
Am I just a package manager?
You pass butter
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.
The new `uv format` is just a shortcut for `uv run --with ruff ruff`.
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.
Why would a type checker need to call a package manager?
Can't you just do this? Why bundle?
The native integration offers persistent configuration, caching, and project-aware behavior that uvx (which just creates an ephemeral venv) doesn't provide.
I would imagine that a person who is seriously concerned about any of that would just install a standalone version of ruff. Given the existence of uvx, this addition seems like feature creep to me.
It's not bundled. `uv format` will use the `ruff` binary and more or less run `uvx ruff format` behind the scene.
It's this "more or less" that is a problem. More complication, less reliability.
Because that's a way less obvious command.
that’s a bit slow typically
so install ruff?
sure, I do, I was responding to someone who asked why not use uvx to run ruff
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.
Also needs to make sorting imports a default.
and stop removing extra leading whitespace before inline comments (#7684)
FWIW, you can pretty easily script this sort of thing. In Bash it can even be a function added to your ~/.bashrc .
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.
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.
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.
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.
You can align it by hand, if you want.
no one is proposing removing the sub-commands, only adding a shortcut that calls both
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.
> 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?
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.
> 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.
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.
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.
Well, the same functionality used to be bundled into rye before the switch to uv. I appreciate having one less dependency to declare again.
Oh neat. I wonder if they are integrating everything into uv then.
Well that title was a lot more interesting without the parentheses that HN automatically removed.
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.`)
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.
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 :)
Yeah the reaction is weird. It's 100% optional. People just love to complain.
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
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?
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.
You know what would be easier, "no."
Memes aside, the conceptual grouping of tools does matter.
Cause one is a formatter and the other is a package manager. That shouldn’t be hard to understand.
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
- mix format
too!
`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.
Is it just me, or do other people also have the impression that a lot of sock puppets are advertising for the Astral company on the internet?
That said, I may not have installed super complex packages, but for years now I have never ever experienced one situation (on Windows, ok) where pip did not just work. For me, pip is the way.
I also have the Python folder be a Git repo, and every `pip install` is a commit, and every project is a branch. Why so difficult?
I love ruff and I love uv and I’m sure I will ty as soon as it’s ready but please keep them separate.
A Foolish Consistency is the Hobgoblin of Little Minds
https://peps.python.org/pep-0008/#a-foolish-consistency-is-t...
I wonder how a code formatting tool is going to implement that.
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…
Every single time someone asks "why?" in this thread, the answer is "well cargo does it too". Not sure what to think about that.
Not all devs have very deep knowledge of the ecosystem, some will get to use a tool only if it's part of the default set of tools they're provided. Plus, it saves on memorizing a name if you only use python once in a long while. There just isn't much of a reason not to.
I landed in python last year, the pre uv time for me. The language itself is fine, but the project organization sucked. What kind of folder structure to choose? Do I use pip, env, pipenv, poetry? How to format, and with which settings? I've read tens of blog post, all giving different choices, all equally reasonable, all having some downsides.
The great thing about uv is not that their choices are best, it's that the choices have been made, the gordian knots cut. There is a good enough standard to build upon. Future python projects will look a lot more like each other, and less time will be wasted on organizational minutiae.
As someone who has worked on package managers quite a bit in the past, and for that examined prior art across package managers, that's because Cargo is doing things very well on almost all fronts. Partially because of their RFC process and partially because they have the luxury of being a "newer" package manager that doesn't have to live with ecosystem baggage going many decades back.
There are/were definitely some weaker spots with Cargo (e.g. private registry support was meh for some time), but if one were tasked to build a package manager and were only allowed to pick a single one to take inspration from, Cargo is definitely the way to go.
“Cargo does it” is a shortcut for “yes, it’s fucking good”.
the python crowd sure likes reinventing formatters every handful of years huh
uv is taking bun's route and just adding features "willy-nilly"?
Excellent. Love it. Keep on at it, guys.
Anyone from uv reading this? please scrap this thing, there is a separate formatter ruff that anyone ll use if they want a formatter. please do not complicate stuff. ruff ll come with its own configuration. this will have its own config at some point. potential rule clashes, ignore plugins. please do not go in this direction
Ruff and uv are written by the same company, astral
A clean alternative: automatically adding ruff as a tool when creating a new pyproject.toml file, with a command line flag to opt out for the minority who know they don't intend to use ruff. For the majority of users, simplicity is worth an accidental download.
this command is more or less an alias for calling Ruff, it's quite explicitly written in the article
I recognize that uv is very popular but it still feels faddish.
I don't want my package manager to format anything.
I don't want my package manager to lint anything.
I don't want my package manager to `run` anything.
I don't want my package manager to even manage environments (yes yes this one is a bit extreme).
I want to have single purpose tools that work together well.
This way I can have a flexible, composable toolchain that can both adapt to me and my specific project.
For example, I like conda, pip, ruff, mypy, flake8. Someone else might like venv, pip, black, pyright, flake8.
This is the heart of the Unix Philosophy and I feel like it's a philosophy each software community has to reject, suffer due to that rejection, and re-adopt on a regular basis. I'd rather we skip the suffering bit.
As someone using formating tools on IDE since the 1990's and UNIX indent as well, I really don't get the hype for formatters.
Even moreso in the LLM age of tooling and coding agents.
It's a minor issues in teams where people use inconsistent formatting. This causes needless complications when merging code and additional work related to resolving conflicts that shouldn't exist to begin with.
Some languages (Go, Rust) have essentially solved this issue to the point where blindly running the formatters these languages have solves the problem and is uncontroversial.
Sadly, the language of choice for me (Kotlin) has a big unaddressed problem here where what the IDE does for formatting and what independent formatting tools do are two things that are hard to align for mostly the historical reasons that what the IDE does is fragmented over different bits of code that don't listen to the same configuration. There is a lot of variation in preferences for indentation, where to put new lines, line length, what order to put imports in, which imports to use wildcards for (if any at all), etc. Particularly imports are a problem because the bit of code that organizes imports is separate from the bit of code that formats code in the IDE.
The common solution of using IDE plugins to work around this is a bit of a kludge. The proper solution would be a more sane way to just make the IDE externally configurable so that build tools can make the IDE do exactly the same as what they do without requiring users to manually configure their IDEs just right by installing plugins or fiddling with configuration. This stuff should not be user controllable if there is a build file that defines the proper formatting.
Coding agents actually add to this problem. Because getting those to stick to formatting conventions is tricky. Unless you have tools that just fix that properly.
So good change in uv and probably something I'd be using on my next python project (I do those once in a while).
Easily solvable with SCM pre-commit hooks, at very least since CVS days.
All major IDEs allow to save the format configurations, which can be stored on the repo alongside the code as the team official's configuration.
Coding agents solve this problem in that eventually all programming languages will be as relevant as mastering Assembly is nowadays.
I already do stuff in low code/no code, that in the past I would be manually writing code to sort out those issues.
In the meantime, you can also ask them to format generated code in whatever way one feels like it.
That's exactly what I mean by kludge. And this attitude is exactly the problem and reason why most languages continue to do the wrong thing here.
Your solution requires user discipline and fiddling with things that should just work right without fiddling. And it needs to happen on every development environment. You can't really enforce it except via annoying additional kludges in the form of failing builds.
I've never been on a team where this was done right. I've been on plenty of teams with convoluted half enforced formatting rules (and thousands of violations).
I know how to fix it for my own code. But being able to force everyone I have to work with to do the same thing over and over again is the problem that needs solving. Everybody just shrugs it off and does nothing about it. What are you going to do. It's always been this miserable this way. Industry wide apathy on this topic.
That's why I appreciate what Google did with Go here so much. Not a fan of the language necessarily. But they did the right thing with making code formatting not optional and a compile error to skip. Stuff like this should not be a debate or discussion or a follow this 20 step process to setup your work environment properly but just something that works right (for fuzzy definitions of right) as specified by the build file in the code repository.
It's a minor annoyance that I wish Jetbrains would just take more serious.
DevOps are the disciple that tames the developer team malpractices, it doesn't stop at formating, static analysis, misbehaved dependencies taken directly out of Internet without IT approval, no proper security workflows, there is no need for user disciple with manual steps.
I hope for uv's sake, that the formatting is always optional and that it is not "opinionated" (read: half asses and no way to configure it), but configurable. And if we get into that, well, it's a whole different tool, that they are trying to put into uv. Seems like a bad idea.