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

401–410 of 468 posts

Re: How uv got so fast

#401

Post by zahlman »

pnt12 wrote: post #281
zahlman wrote: post #75

Earlier quoted context omitted.

> If setup.py was working okay for folks, what incentivized them to start using pyproject.toml? It wasn't working okay for many people, and many others haven't started using pyproject.toml. For what I consider the most egregious example: Requests is one of the most popular libraries, under the PSF's official umbrella, which uses only Python code and thus doesn't even need to be "built" in a meaningful sense. It has a…

That's really unfortunate, and it sounds like a quick thing to fix. Is there a pull request with that?

There's been a branch for it (https://github.com/psf/requests/tree/hatchling) for a little while apparently; I guess they won't merge it until absolutely necessary for the 2.33 release. But that is still just over a year after I offered (https://github.com/psf/requests/issues/6775).

... Ah, I got confused for a bit. When I first noticed the `pyproject.toml` deficiency, it was because Requests was affected by the major Setuptools 72 backwards incompatibility. Then this year they were hit again by the major Setuptools 78 backwards incompatibility (which the Setuptools team consciously ignored in testing because Requests already publishes their own wheel, so this only affected the build-from-source purists like distro maintainers). See also my writeup https://lwn.net/Articles/1020576/ .

Re: How uv got so fast

#402

Post by zahlman »

kibwen wrote: post #355
TheDong wrote: post #297

Earlier quoted context omitted.

For whatever it's worth, the toml library uv uses doesn't support streaming parsing: https://github.com/toml-rs/toml/issues/326

I'm not sure if it even makes sense for a TOML file to be "read incrementally", because of the weird feature of TOML (inherited from INI conventions) that allow tables to be defined in a piecemeal, out-of-order fashion. Here's an example that the TOML spec calls "valid, but discouraged": [fruit.apple] [animal] [fruit.orange] So the only way to know that you have all the keys in a given table is to literally read the…

I don't think that's worse than having to search an arbitrary distance for a matching closing bracket. There are tasks where you can start working knowing that a given array in the data might be appended to later (similarly for objects).

Re: How uv got so fast

#403

Post by Someone »

Nextgrid wrote: post #301
baby wrote: post #221

Earlier quoted context omitted.

That doesn't make any sense. You can do open source by yourself and not accept any input. How's the company behind uv making money?

> How's the company behind uv making money? It doesn't have to make money now . But it's clearly pouring commercial-project-level of resources into uv, on the belief they will somehow recoup that investment later on.

It doesn’t hav eto make money ever on us for it to be worth it to them.

If you’re a Python shop, compare

- writing uv and keeping it private makes package management easier for your own packages

- writing uv and opening it up, and getting all/most third party libs to use it makes package management easier for your own packages and third party packages you use

Re: How uv got so fast

#404

Post by stephendause »

NewsaHackO wrote: post #326
DrawTR wrote: post #182

Earlier quoted context omitted.

Editing the post to switch five "it's X not Y"s[1] is pretty disappointing. I wish people were more clear with their disclosure of LLM editing. [1]: https://github.com/andrew/nesbitt.io/commit/0664881a524feac4...

I recsind my previous statement. Also, people have to stop putting everything on github.

Why? To me, hosting previous versions of an article in a public git repo adds transparency. Or perhaps you are talking about GitHub specifically?

Re: How uv got so fast

#405

Post by xvector »

eru wrote: post #388
xvector wrote: post #181

Earlier quoted context omitted.

Hard disagree, most of my coworkers make well north of $1M and office politics is at an all time high. I believe office politics happens when there are simply too many people at a company or org.

What industry is that, if I may ask?

Tech

Re: How uv got so fast

#406

Post by zzzeek »

BiteCode_dev wrote: post #256
zzzeek wrote: post #142

Earlier quoted context omitted.

> real threads, no need for multi-processing parallel downloads don't need multi-processing since this is an IO bound usecase. asyncio or GIL-threads (which unblock on IO) would be perfectly fine. native threads will eventually be the default also.

Indeed, but unzipping while downloading do. Analysing multiple metadata files and exporting lock data as well. Now I believe unzip releases the GIL already so we could already benefit from that and the rest likely don't dominate perfs. But still, rust software is faster on average than python software. After all, all those things are possible in python, and yet we haven't seen them all in one package manager before u…

> Maybe the strongest advantage of rust, on top of very clean and fast default behaviors, is that it attracts people that care about speed, safety and correctness. And those devs are more likely to spend time implementing fast software.

people who have this opinion should use Rust, not Python, at all. if Python code does not have sufficient speed, safety, and correctness for someone, it should not be used. Python's tools should be written in Python.

> The killer feature is, being a stand alone executable, it bypasses all python bootstrapping problems.

I can't speak for windows or macs but on Linux, system pythons are standard, and there is no "bootstrapping problem" using well known utilities that happen to be written in Python.

Re: How uv got so fast

#407

Post by zahlman »

akoboldfrying wrote: post #328
Pawamoy wrote: post #273

Earlier quoted context omitted.

No. When such upper bounds are respected, they contaminate other packages, because you have to add them yourself to be compatible with your dependencies. Then your dependents must add them too, etc. This brings only pain. Python 4 is not even a thing, core developers say there won't ever be a Python 4.h

> you have to add them yourself to be compatible with your dependencies This is no more true for version upper bounds than it is for version lower bounds, assuming that package installers ensure all package version constraints are satisfied. I presume you think version lower bounds should still be honoured?

The point is that you can know that a lower bound is necessary at the time of publication; an upper bound is either speculative or purely defensive, and has possibly unnecessary consequences for your dependents.

Re: How uv got so fast

#409

Post by ldng »

That might be how uv got fast but that is not why it got popular.

PyPA has been a mess for a very long time for in-fighting, astroturfing, gatekeeping and so on with pip being the battlefield. The uv team just did one thing that PyPA & co stopped doing a long time ago (if they ever did ...) : actually solving pain point of their user and never saying "it's not possible because [insert bullshit]" or reply "it's OSS, do it yourself" to then reject the work with attitude and baseless argument.

They listened to their user's issues and solved their pain points without denying them. period.

Re: How uv got so fast

#410

Post by kibwen »

zahlman wrote: post #402
kibwen wrote: post #355

Earlier quoted context omitted.

I'm not sure if it even makes sense for a TOML file to be "read incrementally", because of the weird feature of TOML (inherited from INI conventions) that allow tables to be defined in a piecemeal, out-of-order fashion. Here's an example that the TOML spec calls "valid, but discouraged": [fruit.apple] [animal] [fruit.orange] So the only way to know that you have all the keys in a given table is to literally read the…

I don't think that's worse than having to search an arbitrary distance for a matching closing bracket. There are tasks where you can start working knowing that a given array in the data might be appended to later (similarly for objects).

It's worse than having to parse a matching bracket, because any context where you have an item defined via nested brackets is going to be a subset of this use case. But yes, that doesn't mean you couldn't do some theoretical eager processing, but it's going to be context dependent. For example, consider a Cargo.toml file, where we've processed the `features` key for a given dependency. Is it safe to begin compiling that dependency with the given set of features before we finish parsing the file? No, because there might be a `default-features=false` key that applies to this dependency later in the file. In a format where tables weren't allowed to be split, the mere act of parsing a single, self-contained dependency entry would be enough to know for certain that no such `default-features` key exists. Not all potential keys are going to require this sort of consideration, but it could be a footgun depending on the semantics of your schema.
Post reply on HN