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

331–340 of 468 posts

Re: How uv got so fast

#331

Post by jacquesm »

aragilar wrote: post #306
Perseids wrote: post #272

Earlier quoted context omitted.

You misunderstand. The physicists are developing their own software to analyze their experimental data. They typically have little software development experience, but there is seldom someone more knowledgeable available to support them. Making matters worse, they often are not at all interested in software development and thus also don't invest the time to learn more than the absolute minimum necessary to solve thei…

Honestly, they should be using conda (if they're working on their laptops) and the cluster package manager otherwise.

Conda has slowly but surely gone down the drain as well. It used to be bullet proof but there too you now get absolutely unsolvable circular dependencies.

Re: How uv got so fast

#332

Post by lillecarl »

woodruffw wrote: post #210
dddgghhbbfblk wrote: post #128

Earlier quoted context omitted.

Why would you want to slow down the more common thing instead of the less common thing? I'm not following that at all. That's why I asked if that's backwards.

Because you only slow down the more common thing once, and the less common thing is slower in absolute terms.

uv optimizes for the common usecase: You will install more packages than you will import new packages.

Re: How uv got so fast

#333

Post by cmrx64 »

mattkevan wrote: post #105
fleebee wrote: post #54

Earlier quoted context omitted.

You're probably right about the latter point, but I do wonder how hard it'd be to mask the default "marketing copywriter" tone of the LLM by asking it to assume some other tone in your prompt. As you said, reading this stuff is taxing. What's more, this is a daily occurrence by now. If there's a silver lining, it's that the LLM smells are so obvious at the moment; I can close the tab as soon as I notice one.

It’s pretty easy. I’ve written a fairly detailed guide to help Claude write in my tone of voice. It also coaxes it to avoid the obvious AI tells such as ‘It’s not X it’s Y’ sentences, American English and overuse of emojis and em dashes. It’s really useful for taking my first drafts and cleaning them up ready for a final polish.

https://ember.dev ’s deeper pages (not the blog, but the “resumelike” project pages) was written by claude with guidance and a substantial corpus of my own writing and i still couldn’t squash out all the GPTisms in the generation passes. probably net waste of time, for me, for writing.

Re: How uv got so fast

#334

Post by cmrx64 »

breischl wrote: post #98
wging wrote: post #93

Earlier quoted context omitted.

I think the article is being careful not to say uv ignores _all_ upper bound checks, but specifically 4.0 upper bound checks. If a package says it requires python < 3.0, that's still super relevant, and I'd hope for uv to still notice and prevent you from trying to import code that won't work on python 3. Not sure what it actually does.

I read the article as saying it ignores all upper-bounds, and 4.0 is just an example. I could be wrong though - it seems ambiguous to me. But if we accept that it currently ignores any upper-bounds checks greater than v3, that's interesting. Does that imply that once Python 4 is available, uv will slow down due to needing to actually run those checks?

That would deliver a blow to the integrity of the rest of that section because those sorts of upper bound constraints immediately reducible to “true” cannot cause backtracking of any kind.

Re: How uv got so fast

#335

Post by cmrx64 »

eviks wrote: post #218
zahlman wrote: post #118

Earlier quoted context omitted.

> 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?

rtld does a lot of work even in “static” binaries to rewrite relocations even in “unused parts” of any PIE (which should be all of them today) and most binaries need full dyld anyway.

Re: How uv got so fast

#336

Post by scotty79 »

andy99 wrote: post #42

I remain baffled about these posts getting excited about uv’s speed. I’d like to see a real poll but I personally can’t imagine people listing speed as one of the their top ten concerns about python package managers. What are the common use cases where the delay due to package installation is at all material? Edit to add: I use python daily

For me speed was irrelevant however uv was the first Python project manger with tolerable ui that I encountered. I never before done any serious development in Python because I just refused dealing with venvs requirements.txt and whatever. When a script used a dependancy or another Python version I installed it system wide. uv is perfectly usable, borderline pleasent. But I'm sure the speed helps.

Re: How uv got so fast

#337

Post by riazrizvi »

andy99 wrote: post #42

I remain baffled about these posts getting excited about uv’s speed. I’d like to see a real poll but I personally can’t imagine people listing speed as one of the their top ten concerns about python package managers. What are the common use cases where the delay due to package installation is at all material? Edit to add: I use python daily

Probably 90% of ppl commenting here are focused on managing their own Python installs and mostly don’t care about speed. uv seems to be designed for enterprise, for IT management of company wide systems, and this post is, I’m guessing, a little promotional astroturfing. For most of us, uv solves a low priority problem.

Re: How uv got so fast

#338

Post by firesteelrain »

adrian17 wrote: post #303
firesteelrain wrote: post #287

Earlier quoted context omitted.

Why not just use a Python container rather than rely on having the latest binary installed on the system? Then venv inside the container. That would get you the “venv of a version” that you are referring to

It's more complex and heavier than using uv. I see docker/vm/vagrant/etc as something as something I reach for when the environment I want is too big, too fancy or too nondeterministic to manually set up locally; but the entire point is that "plain Python with some dependencies" really shouldn't qualify as any of these (just like build environment for a random Rust library). Also, what do you do when you want your to…

> what do you do when you want your to locally test your codebase across many Python versions?

I haven’t found that there was any breakage across Python 3.x. Python 2.x to 3.x yes.

Anyways, this all could be wrapped in a CICD job and automated if you wanted to test across all versions.

Re: How uv got so fast

#339

Post by optionalsquid »

curiousgal wrote: post #228
blibble wrote: post #175

Earlier quoted context omitted.

conda can take an hour to tell you your desired packages are unsatisifiable saying that, other than the solver, most of what uv does is always going to be IO bound

People criticising conda's solver prove they haven't used it in years.

You can also use pixi[1] if you want conda with uv's solver, that does appears to be faster than the mamba solver. Though the main reasons I recommend pixi, are that it doesn't have a tendency to break random stuff due to polluting your environment by default, and that it does a much better job of making your environments reproducible, among another benefits

[1] https://pixi.sh/

Re: How uv got so fast

#340

Post by mepiethree »

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.

I definitely found the thesis insightful. The actual content stopped feeling insightful to me in the “What uv drops” section, where cut features were all listed as if they had equal weight, all in the same breathless LLM style
Post reply on HN