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

191–200 of 401 posts

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

#191

Post by aragilar »

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.

That problem is very much not pip (pip is only the installer), the issue is: * We have a conflict between being easy to use (people don't need to work out which version of cuda/which gpu settings/libraries/etc. to use) vs install size (it's basically the x86 vs arm issue, except at least 10 fold larger). Rather than making it the end-users problem, packages bundle all possible options into a single artifact (MacOS does this same, but see the 10 fold larger issue). * The are almost fundamental assumptions (and the newer Python packaging tools, including uv, very much rely on these) that Python packaging makes that are inherently about how a system should act (basically, frozen, no detection available apart from the "OS"), which do not align with having hardware/software that much be detected. One could do this via sdists, but Windows plus the issues around dynamic metadata make this a non-starter (and hence tools like conda, spack and others from the more scientific side of the ecosystem have been created—notably on the more webby side, this problems are solved either via vendoring non-python libraries, or making it someone/something else's problem, hence docker or the cloud for databases or other companion services). * Frankly, more and more developers have no idea how systems are built (and this isn't just a Python issue). Docker lets people hide their sins, with magical invocations that just work (and static linking in many cases sadly does the same). There are tools out of the hyperscalars which are designed to solve these problems, but they solve it by creating tools that experts can wrangle many systems and hence imply you have a team which can do the wrangling.

Can this be solved? Maybe, but not by a new tool (on its own). It would require a lot of devs who may not see much improvement to their workflow change their workflow for others (to newer ones which remove the assumptions which are built in to the current workflows), plus a bunch of work by key stakeholders (and maybe even the open sourcing of some crown jewels), and I don't see that happening.

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

#192

Post by selectnull »

gyomu wrote: post #168
datadeft wrote: post #166

Now we should just figure out why to stop here. Why not write everything in Rust? Recently I have moved all my projects to Rust from Python and never looked back. Of course we need projects like Torch and we are not yet there, but those simpler projects that do not require GPU libraries Rust is great.

What’s a good flask (+jinja) equivalent for rust?

Actix + minijinja

Actix is just one of many web frameworks, minijinja is an implementation of jinja2, by the original author.

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

#193

Post by noodletheworld »

wiseowise wrote: post #188
iandanforth wrote: post #79

Since this seems to be a love fest let me offer a contrarian view. I use conda for environment management and pip for package management. This neatly separates the concerns into two tools that are good at what they do. I'm afraid that uv is another round of "Let's fix everything" just to create another soon to be dead set of patterns. I find nothing innovative or pleasing in its design, nor do I feel that it is parti…

> soon to be dead set of patterns. Dozens of threads of people praising how performant and easy uv is, how it builds on standards and current tooling instead of inventing new incompatible set of crap, and every time one comment pops up with “akshually my mix of conda, pyenv, pipx, poetry can already do that in record time of 5 minutes, why do you need uv? Its going to be dead soon”.

So what?

If someone doesn’t want to use it, or doesn’t like it, or is, quite reasonably skeptical that “this time it’ll be different!” … let them be.

If it’s good, it’ll stand on its own despite the criticism.

If it can’t survive with some people disliking and criticising it is, it deserves to die.

Right? Live and let live. We don’t have to all agree all the time about everything.

uv is great. So use it if you want to.

And if you don’t, that’s okay too.

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

#194

Post by selectnull »

BiteCode_dev wrote: post #149
BeetleB wrote: post #44

It seems like uv doesn't target replacing pipenv...? No mention of it in their docs and there is an open Github issue about it. I have yet to learn uv, but I intend to. Still, having to ".venv/bin/activate" to activate the virtualenv is a lot less ergonomic than "pipenv shell".

You don't need to activate anything with uv, all commands do it in the venv automatically, and including uv run.

While working in Django projects, one would prefer to have an environment activarted to perform all kinds of django-admin commands, I certainly wouldn't want to do via `uv run`.

Also, `nvim` is started with an environment activated if you want all the LSP goodies.

`uv run` is good for some things, but I prefer to have my venv activated as well.

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

#195

Post by sieve »

aragilar wrote: post #191
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.

That problem is very much not pip (pip is only the installer), the issue is: * We have a conflict between being easy to use (people don't need to work out which version of cuda/which gpu settings/libraries/etc. to use) vs install size (it's basically the x86 vs arm issue, except at least 10 fold larger). Rather than making it the end-users problem, packages bundle all possible options into a single artifact (MacOS do…

> people don't need to work out which version of cuda/which gpu settings/libraries/etc. to use

This is not true in my case. The regular pytorch does not work on my system. I had to download a version specific to my system from the pytorch website using --index-url.

> packages bundle all possible options into a single artifact

Cross-platform Java apps do it too. For e.g., see https://github.com/xerial/sqlite-jdbc. But it does not become a clusterfuck like it does with python. After downloading gigabytes and gigabytes of dependencies repeatedly, the python tool you are trying to run will refuse to do so for random reasons.

You cannot serve end-users a shit-sandwich of this kind.

The python ecosystem is a big mess and, outside of a few projects like uv, I don't see anyone trying to build a sensible solution that tries to improve both speed/performance and packaging/distribution.

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

#196

Post by BossingAround »

barosl wrote: post #43

A very well written article! I admire the analysis done by the author regarding the difficulties of Python packaging. With the advent of uv, I'm finally feeling like Python packaging is solved. As mentioned in the article, being able to have inline dependencies in a single-file Python script and running it naturally is just beautiful. #!/usr/bin/env -S uv run # /// script # dependencies = ['requests', 'beautifulsoup4…

This looks horrible for anything but personal scripts/projects. For anything close to production purposes, this seems like a nightmare.

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

#197

Post by snow_flake »

mufasachan wrote: post #175
oefrha wrote: post #144

Earlier quoted context omitted.

Conda is the dreaded solution to the dreadful ML/scientific Python works-on-my-computer dependency spaghetti projects. One has to be crazy to suggest it for anything else. uv hardly occupies the same problem space. It elevates DX with disciplined projects to new heights, but still falls short with undisciplined projects with tons of undeclared/poorly declared external dependencies, often transitive — commonly seen in…

Eh, ML/scientific Python is large and not homogeneous. For code that should work on cluster, I would lean towards a Docker/container solution. For simpler dependancy use cases, pyenv/venv duo is alright. For some specific lib that have a conda package, it might be better to use conda, _might be_. One illustration is the CUDA toolkit with torch install on conda. If you need a basic setup, it would work (and takes age)…

I always enjoyed the "one-stop" solution with conda/mamba that installed the right version of cudatoolkit along with pytorch. How do you handle that without conda? (I'm genuinely ask because I never had to actually care about it.) If I manually install it, it looks like it is going to be a mess if I have to juggle multiple versions.

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

#198

Post by wiseowise »

sph wrote: post #159
inejge wrote: post #141

Earlier quoted context omitted.

I don't think it's particularly problematic, uv the concurrency library and uv the Python tool cover such non-overlapping domains that opportunities for confusion are minimal. (The principle is recognized in trademark law -- some may remember Apple the record label and Apple the computer company. They eventually clashed, but I don't see either of the uv's encroaching on the other's territory.)

Sure, there are so few backend Node.js engineers. Let alone game engine developers and Blender users with their UV mapping tools. None of these people will ever encounter Python in their daily lives.

[flagged]

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

#199

Post by rfoo »

conradev wrote: post #112
d0mine wrote: post #81

Earlier quoted context omitted.

What makes you think it doesn't?

This from above: > I just used find to locate as many libtorch_cpu.dylib files as possible on my laptop and deleted 5.5GB of them but maybe it wasn’t actually 5.5 GB!

It was like a dozen different versions of libtorch_cpu.dylib. So hardlink does not help.

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

#200

Post by rat87 »

conradev wrote: post #112
d0mine wrote: post #81

Earlier quoted context omitted.

What makes you think it doesn't?

This from above: > I just used find to locate as many libtorch_cpu.dylib files as possible on my laptop and deleted 5.5GB of them but maybe it wasn’t actually 5.5 GB!

It probably is 5.5GB. UV caches versions of packages and symlinks to them but pytorch is infamous for many different versions especially for different features.

And since its compiled dependency even if UV was to attempt the the more complicated method of symlinking to use a single version of identical files it wouldn't help much. You'd probably need to store binary diffs or chunks of files that are binary identical, at that point your code would probably start to resemble a file system in user space and time to switch to a particular version of the files (ie create thek as qctual files in filesystem) would be much higher.

Also I believe uvs cache is separate from the pip cache so you could have different copies in both.

I think there's a uv cache prune command. Arguably it should offer to install a from job to do it periodically

Post reply on HN