Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A year of uv: pros, cons, and should you migrate

bitecode.dev

Post reply on HN
Print view View original

21–30 of 401 posts

Re: A year of uv: pros, cons, and should you migrate

#21

Post by sieve »

RockRobotRock wrote: post #18
sieve wrote: post #12

Well, big fan of uv. But... the 86GB python dependency download cache on my primary SSD, most of which can be attributed to the 50 different versions of torch, is testament to the fact that even uv cannot salvage the mess that is pip. Never felt this much rage at the state of a language/build system in the 25 years that I have been programming. And I had to deal with Scala's SBT ("Simple Build Tool") in another life.

A lot of that is cuda blobs, right?

ROCm. About 40%. But there is duplication there as well. Two 16GB folders containing the exact same version.

Re: A year of uv: pros, cons, and should you migrate

#22

Post by arnath »

I think the biggest praise I can give uv is that as a non Python dev, it makes Python a lot more accessible. The ecosystem can be really confusing to approach as an outsider. There’s like 5 different ways to create virtual environments. With uv, you don’t have to care about any of that. The venv and your Python install are just handled for you by ‘uv run’, which is magic.

Re: A year of uv: pros, cons, and should you migrate

#23

Post by __MatrixMan__ »

3l3ktr4 wrote: post #8

I thought this was going to be about the UV rays from the sun... But it's another python package manager. We're running out of names.

Were you considering migrating to ultraviolet light? Vitamin D is indeed important, but that mutagenesis is no joke. I'd suggest against it.

Re: A year of uv: pros, cons, and should you migrate

#24

Post by conradev »

simonw wrote: post #16
sieve wrote: post #12

Well, big fan of uv. But... the 86GB python dependency download cache on my primary SSD, most of which can be attributed to the 50 different versions of torch, is testament to the fact that even uv cannot salvage the mess that is pip. Never felt this much rage at the state of a language/build system in the 25 years that I have been programming. And I had to deal with Scala's SBT ("Simple Build Tool") in another life.

I don't think pip is to blame for that. PyTorch is sadly an enormous space hog. I just started a fresh virtual environment with "python -m venv venv" - running "du -h" showed it to be 21MB. After running "venv/bin/pip install torch" it's now 431MB. The largest file in there is this one: 178M ./lib/python3.10/site-packages/torch/lib/libtorch_cpu.dylib There's a whole section of the uv manual dedicated just to PyTorch:…

uv should hard link files if they’re identical like Nix does

If a package manager stores more than it needs to, it is a package manager problem.

Re: A year of uv: pros, cons, and should you migrate

#25

Post by teruakohatu »

Ufvasl wrote: post #15
cjohnson318 wrote: post #9

Honest question: is uv more reproducible/portable than cramming your Python project into a Docker container? I've used pyenv, pip, venv, and a couple of other things, and they all work fine, at first, in simple scenarios.

Docker isn't a project manager, I'm struggling to see the comparison. If you have an app (api/web etc) you would use uv to manage dependencies, lock files and a locam virtual environment for development, and then you could install the same dependencies and the project in a docker image also for deployment.

People certainly use Docker for this purpose. Need a new package? Add a pip install line and rebuild the image.

I agree it isn’t the best use of Docker, but with the hell that is conda (and I say this as someone who likes conda more than most other options) and what can feel like insanity managing python environments, Docker isn’t the worst solution.

All that said, I moved to uv last year and have been loving it.

Re: A year of uv: pros, cons, and should you migrate

#26

Post by IgorPartola »

sieve wrote: post #21
RockRobotRock wrote: post #18

Earlier quoted context omitted.

A lot of that is cuda blobs, right?

ROCm. About 40%. But there is duplication there as well. Two 16GB folders containing the exact same version.

Sounds like a great use case for ZFS’s deduplication at block level.

Re: A year of uv: pros, cons, and should you migrate

#27

Post by nighthawk454 »

simonw wrote: post #16
sieve wrote: post #12

Well, big fan of uv. But... the 86GB python dependency download cache on my primary SSD, most of which can be attributed to the 50 different versions of torch, is testament to the fact that even uv cannot salvage the mess that is pip. Never felt this much rage at the state of a language/build system in the 25 years that I have been programming. And I had to deal with Scala's SBT ("Simple Build Tool") in another life.

I don't think pip is to blame for that. PyTorch is sadly an enormous space hog. I just started a fresh virtual environment with "python -m venv venv" - running "du -h" showed it to be 21MB. After running "venv/bin/pip install torch" it's now 431MB. The largest file in there is this one: 178M ./lib/python3.10/site-packages/torch/lib/libtorch_cpu.dylib There's a whole section of the uv manual dedicated just to PyTorch:…

Testing this out locally, repro'd pretty similar numbers on macOS ARM and docker. Unfortunately the CPU-only build isn't really any smaller either, thought it was

Re: A year of uv: pros, cons, and should you migrate

#28

Post by IAmNotACellist »

simonw wrote: post #17
IAmNotACellist wrote: post #11

Is uv better than micromamba? I tried using uv once and got some big ugly error I don't remember, and that was the end of that, whereas mm just worked (perhaps due to my familiarity). It was a project with the usual situation, i.e., torch, numpy, cuda support, nvcc, all had to play nicely together and satisfy requirements.txt.

How long ago did you try uv? It just hit its 12 month birthday a few days ago and has evolved a LOT on those past 12 months. One of the problems I ran into with it was patched out within days of me first hitting it. https://simonwillison.net/2024/Nov/8/uv/

Just a few weeks ago. Sadly I can't remember the specifics but meta-management toolchains are always a hard sell if what you currently have works and is Good Enough. mm is quite fast compared to anaconda, though not perfect. Maybe I'd also benefit from uv having an environment import feature, since I have like 30 *conda environments by now.

Re: A year of uv: pros, cons, and should you migrate

#29

Post by sieve »

simonw wrote: post #20
sieve wrote: post #19

Earlier quoted context omitted.

I use uv pip to install dependencies for any LLM software I run. I am not sure if uv re-implements the pip logic or hands over resolution to pip. But it does not change the fact that I have multiple versions of torch + multiple installations of the same version of torch in the cache. Compare this to the way something like maven/gradle handles this and you have to wonder WTF is going on here.

uv implements its own resolution logic independently of pip. Maybe your various LLM libraries are pinning different versions of Torch? Different Python versions each need their own separate Torch binaries as well. At least with uv you don't end up with separate duplicate copies of PyTorch in each of the virtual environments for each of your different projects!

> Different Python versions each need their own separate Torch binaries as well

Found this the hard way. Something to do with breakage in ABI perhaps. Was looking at the way python implements extensions the other day. Very weird.

Post reply on HN