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

How uv got so fast

nesbitt.io

Post reply on HN
Print view View original

211–220 of 468 posts

Re: How uv got so fast

#211

Post by VerifiedReports »

IshKebab wrote: post #96
VerifiedReports wrote: post #36

So... will uv make Python a viable cross-platform utility solution? I was going to learn Python for just that (file-conversion utilities and the like), but everybody was so down on the messy ecosystem that I never bothered.

Yes, uv basically solves the terrible Python tooling situation. In my view that was by far the biggest issue with Python - a complete deal-breaker really. But uv solves it pretty well. The remaining big issues are a) performance, and b) the import system. uv doesn't do anything about those. Performance may not be an issue in some cases, and the import system is ... tolerable if you're writing "a python project". If y…

Thanks! I don't really think about importing stuff (which maybe I should), because I assume I'll have to write any specialized logic myself. So... your outlook is encouraging.

Re: How uv got so fast

#213

Post by yieldcrv »

pecheny wrote: post #25

The content is nice and insightful! But God I wish people stopped using LLMs to 'improve' their prose... Ironically, some day we might employ LLMs to re-humanize texts that had been already massacred.

> Ironically, some day we might employ LLMs to re-humanize texts

I heard high school and college students are doing this routinely so their papers don't get flagged as AI

this is whether they used an LLM for the whole assignment or wrote it themselves, has to get pass through a "re-humanizing" LLM either way just to avoid drama

Re: How uv got so fast

#214

Post by WD-42 »

Nextgrid wrote: post #158
orliesaurus wrote: post #148

The most surprising part of uv's success to me isn't Rust at all, it's how much speed we "unlocked" just by finally treating Python packaging as a well-specified systems problem instead of a pile of historical accidents. If uv had been written in Go or even highly optimized CPython, but with the same design decisions (PEP 517/518/621/658 focus, HTTP range tricks, aggressive wheel-first strategy, ignoring obviously de…

It's not just greenfield-ness but the fact it's a commercial endeavor (even if the code is open-source). Building a commercial product means you pay money (or something they equally value) to people to do your bidding. You don't have to worry about politics, licensing, and all the usual FOSS-related drama. You pay them to set their opinions aside and build what you want, not what they want (and if that doesn't work,…

I don't know what you think "typical Foss projects" are but in my experience they are exactly like your systemd example: one person that does what they want and share it with the world. The rest of your argument doesn't really make any sense with that in mind.

Re: How uv got so fast

#215

Post by jlubawy »

aswegs8 wrote: post #22

uv seems to be a pet peeve of HN. I always thought pipenv was good but yeah, seems like I was being ignorant

Came here to ask about pipenv. As someone who does not use python other than for scripting, but also appreciates the reproduceability that pipenv provides, should I be using uv? My understanding is that pipenv is the better successor to venv and pip (combined), but now everyone is talking about uv so to be honest it's quite confusing.

Edit: to add to what my understanding of pipenv is, the "standard/approved" method of package management by the python community, but in practice is it not? Is it now uv?

Re: How uv got so fast

#216

Post by crote »

baby_souffle wrote: post #157
orliesaurus wrote: post #148

The most surprising part of uv's success to me isn't Rust at all, it's how much speed we "unlocked" just by finally treating Python packaging as a well-specified systems problem instead of a pile of historical accidents. If uv had been written in Go or even highly optimized CPython, but with the same design decisions (PEP 517/518/621/658 focus, HTTP range tricks, aggressive wheel-first strategy, ignoring obviously de…

I largely agree but don't want to entirely discount the effect that using a compiled language had. At least in my limited experience, the selling point with the most traction is that you don't already need a working python install to get UV. And once you have UV, you can just go! If I had a dollar for every time I've helped somebody untangle the mess of python environment libraries created by an undocumented mix of p…

So basically, it avoids the whole chicken-and-egg problem. With UV you've simply always got "UV -> project Python 1.23 -> project". UV is your dependency manager, and your Python is just another dependency.

With other dependency managers you end up with "system Python 3.45 -> dep manager -> project Python 1.23 -> project". Or worse, "system Python 1.23 -> dep manager -> project Python 1.23 -> project". And of course there will be people who read about the problem and install their own Python manager, so they end up with a "system Python -> virtualenv Python -> poetry Python -> project" stack. Or the other way around, and they'll end up installing their project dependencies globally...

Re: How uv got so fast

#217

Post by rao-v »

I have to say it's just lovely seeing such a nicely crafted and written technical essay. It's so obvious that this is crafted by hand, and reading it just reemphasises how much we've lost because technical bloggers are too ready to hand the keys over to LLMs.

Re: How uv got so fast

#218

Post by eviks »

zahlman wrote: post #118
eviks wrote: post #82

> Every code path you don’t have is a code path you don’t wait for. No, every code path you don't execute is that. Like > No .egg support. How does that explain anything if the egg format is obsolete and not used? Similar with spec strictness fallback logic - it's only slow if the packages you're installing are malformed, otherwise the logic will not run and not slow you down. And in general, instead of a list of irr…

> No, every code path you don't execute is that. Even in compiled languages, binaries have to get loaded into memory. For Python it's much worse. On my machine: $ time python -c 'pass' real 0m0.019s user 0m0.013s sys 0m0.006s $ time pip --version > /dev/null real 0m0.202s user 0m0.182s sys 0m0.021s Almost all of that extra time is either the module import process or garbage collection at the end. Even with cached byt…

> binaries have to get loaded into memory.

Unless memory mapped by the OS with no impact on runtime for unused parts?

> imports related to Requests are deferred

Exactly, so again have no impact?

Re: How uv got so fast

#219

Post by Defletter »

WD-42 wrote: post #214
Nextgrid wrote: post #158

Earlier quoted context omitted.

It's not just greenfield-ness but the fact it's a commercial endeavor (even if the code is open-source). Building a commercial product means you pay money (or something they equally value) to people to do your bidding. You don't have to worry about politics, licensing, and all the usual FOSS-related drama. You pay them to set their opinions aside and build what you want, not what they want (and if that doesn't work,…

I don't know what you think "typical Foss projects" are but in my experience they are exactly like your systemd example: one person that does what they want and share it with the world. The rest of your argument doesn't really make any sense with that in mind.

It depends on governance, for want of a better word: if a project has a benevolent dictator then that project will likely be more productive than one that requires consensus building.

Re: How uv got so fast

#220

Post by crote »

eru wrote: post #171
mkoubaa wrote: post #159

Earlier quoted context omitted.

1000% this. uv is trivially installable and is completely unrelated to installations of python.

I wonder how much Rust's default to statically link almost everything helped here? That should make deployment of uv even easier?

I don't think this makes a meaningful difference. The installation is a `curl | sh`, which downloads a tarball, which gets extracted to some directory in $PATH.

It currently includes two executables, but having it contain two executables and a bunch of .so libraries would be a fairly trivial change. It only gets messy when you want it to make use of system-provided versions of the libraries, rather than simply vendoring them all yourself.

Post reply on HN