Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Nice improvement. For me, uv is the ‘Quicklisp for Python.’ uv just let me enjoy using Python like Quicklisp just makes Common Lisp nicer to use.
I have always been a Lisp devotee, but a few years ago when I started using uv, I then started seeing Python as a language I could really enjoy using so I put effort into making my Python dev setup nearly frictionless.
- uv is the backbone of any modern Python library. I’m excited to see improvements.by stephenlf
- Nonsense. uv is one of many existing build tools. All the items can be done by other programs.
Funny to list OpenAI as an example at the end of the blog post ...
by 310298 - they just implement the modern PEPsby tingletech
- Can uv even be used with C extensions now?by 1aj-187
- Good article. But the Makefile part should really be replaced by tox as a best practice. Tox even has a uv runner now that will handle setting up all the environments.by marknsikora
- A 10% reduction in cache size in exchange for a 4% slowdown doesn't seem obviously worthwhile to me, especially when it comes at an increase in complexity.by CivBase
- >especially when it comes at an increase in complexity.
Or (nasty) bugs hard to debug
by delduca - Making things faster is much easier than making things smaller. I'm sure we can win back a 4% slowdown elsewhere since we have so many more levers to pull from.
- Whereas I made a mistake and bought an underspeced MacBook and my 512GB disk is constantly on the brink of full as I reclaim the last 40 GB over and over from different caches, downloads, and wherever else and had to simply give up on several projects because of their disk usage.
Disk isn't free, especially now.
- Percentages aren't always the right gauge. uv isn't something I run frequently or for long periods of time. It's like a couple seconds every month or whatever. I would rather spend an extra second waiting every year to have hundreds more megabytes all the time.by mminer237
- People say uv is good because it's fast, but honestly I don't care about that. We switched to using it for distribution of our Python-based tools because it makes it very convenient to install directly from a git repository and then to subsequently update from same repository. No need to build a package.by dboreham
- uv is the backbone of any modern Python library.by stephenlf
- I have never gotten the speed argument either. Yes it's noticeably faster - but in all my projects it's 1s vs 0.1s, not enough to make a meaningful difference. Even in their benchmarks, the worst number they ever give for pip is 7s [1] (and those numbers are 2+ years old, with python's improvements pip should be doing a little better now). I just can't say I've ever cared about installing dependencies, something you do once, taking 7s longer. Nor do I care how long CI takes, it running in the background is the point.
The one use I can give it is for running scripts with inline dependencies. I have found it a noticeable improvement over pipx there. But that's more due to needing to parse dependencies every single launch, if it's something I use regularly I end up just installing them normally instead, and it's faster than either.
by apple1417 - It's not such a big deal compared to pip for a typical python package, but a couple of use cases where the speed is a nice feature are tool running with uvx and inline dependencies in scripts - you'll still see something is installed the first time you run the tool/script, but usually it's fast enough to not notice.
One could also make a comparison to another popular tool, conda, which is glacially slow, but that would arguably be unfair since conda does things uv doesn't.
More generally, it's still a nice thing, though. It's just a little less friction. Even a few seconds slower can nudge you towards different behavior
by dimatura - I tried it out successfully for the first time the other day (had 1 false start some months ago). This is after 10 ish years of system wide installs or venvs. I didn't find it fast at all. Every time I went to run the script it spent multiple seconds checking dependencies. Then one time it updated one, which luckily didn't break anything but I did get concerned. I'm sure there're some flags I didn't know to use but uvx was not great. On the other hand, it did seem to install the packages faster than pip.by Neywiny
- For me, the speed is the least interesting part of `uv`. What I like about it is what it bundle into a single bin : Managing installed python version, automatically creating local .venv for the project (I don't like software like pipenv who install the venv who knows where in a global directory of their choosing), support of pyproject.toml, including of the python version declared in it, and running script with dependencies.
None of it is unique to `uv` I believe, but it does it all, reliably, is easy to install, and easy to use. In terms of DX, for my use cases, it beat poetry, pipenv, pyenv (for python version management) and just using pip
by maeln - Maybe I've misunderstood you, but that's not a special advantage of uv. pip has been able to do this for many years.
pip install git+https://github.com/some-org/repoby nchammas - > deduplication at the file level: every file is now stored under its BLAKE3 hash
Blake3 is really a wonderfully fast cryptographic hash. I use it for my own "deduplication / integrity / berzerker" utility (which I made before LLMs were a thing).
If I've got a file named:
then:DSC98731-b3-7b39197a22.JPG
For example my DB can say "any file with a Blake3 hash of 7b39197a22 can always be deleted" or "any file with a Blake3 hash of 887463c09e, if it's got a generic filename like "dscXXXXX" can always be renamed to "20260722jackJohnAtTheBeach-b3-778463c09e.jpg" (or whatever suits you).- if that file doesn't checksum back to 7b39197a22 there's a file integrity problem (amazing and it already helped me troubleshoot issues) - if any other file has the same Blake3 7b39197a22 hash, it's a duplicate - if that 7b39197a22 checksum is in my database, "things can happen".It's really great (and I know several here independently made similar schemes) and Blake3 is an amazing hash for those kind of use.
- Why BLAKE3? I hadn't thought too deeply about it but at some point I settled on https://github.com/Cyan4973/xxHash for similar things.by duskdozer
- It's annoying that most file formats don't checksum their own content.
Even formats which should know better, like SQLite, delegate that to the filesystem, most of which are also not checksumed and which delegate that further to the storage.
PostgreSQL, which prides itself by it's quality and reliability, only turned on checksums by default in the last version, 18.
This is one great benefit of using .zip files as file formats, you get this for free.
by dist-epoch - > I use it for my own "deduplication / integrity / berzerker" utility
Do you have it in a public repo you could share?
by gchamonlive - Another cool thing about BLAKE3 is that it is a merkle tree. Not only it allows for good parallelism, but it also has a lot of cool property for data transfer. For example, you can check for partial validity, which allow for streaming error-detection and resend during the transfer. You only need to have the data and checksum in a way that you can start to reconstruct one or more subtree.by maeln
- For those wondering like me: Blake3 generates hashes of at least 224 bits, not, as a literal reading of that comment indicates, 40 bits (which would be bad for file deduplication, giving you a 50% hash collision after around a million files)by Someone
- As a pip maintainer, I've long been looking at the tradeoffs of uv's cache, it's the biggest item that makes warm installs faster for uv vs. pip. As pip caches the original distributions and then has to unzip them each time, uv caches the unzipped distribution and hard links to it if it can.
But it has always had two major issues:
1. No way to reproduce exact distributions for a "download" command (there is no uv equivalent of "pip download")
2. For people with a lot of different environments the cache grows significantly more than pip
I'm interested to see, at least anecdotally, if this significantly improves 2, then we can perhaps have a two layer caching strategy without the significant disk space cost.
by notatallshaw - Howto use it? sorry for the noob question.
I tried `uv --preview-features content-addressed-cache` and I get an error:
`uv --preview-features content-addressed-cache error: 'uv' requires a subcommand but one was not provided`
by ALLTaken - You might be interested in taking a look at the `uv download` sketch I started on last week https://github.com/astral-sh/uv-dev/pull/875by zanie
- Also as a pip contributor. The only advantage of uv is to have support for parallel async extraction. If pip extracted multiple files/wheels in parallel without being blocked by the GIL, pip could easily match or outcompete uv.
I'm personally not looking forward to any deduplication/hardlink in pip. Hardlinks are very dangerous and system dependent.
It's very dangerous for empty files (init.py, empty.log yet not written). When the user edits one file, all files are modified simultaneously, all venv ever created by the user can be broken by editing one file, which is quite catastrophic.
It's also dangerous for small files with repeated content, for example random settings files that would contain a "1" or "true". Again, when the user edits one file, all files are edited and they were supposed to be different!
Hypothetically, a simple deduplication of binary files (.dll .so) should achieve 50% of the savings without significant drawbacks
I'd venture to say that pip extraction is more optimized than uv in at least one way. We have optimization for empty files (0 bytes) because there is nothing to write and checksum. uv doesn't seem to have the same optimizations, though I could be wrong, I just had a cursory look and my rust is not great. uv should probably review their treatment of empty files, it's counter productive to do any file system operation open/read/write because there is no content, it might be counterproductive to use any cache/comparison/hardlink if it takes more operations than doing nothing.
by user5994461