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

461–468 of 468 posts

Re: How uv got so fast

#461

Post by dent9 »

Mawr wrote: post #418
zahlman wrote: post #236

Earlier quoted context omitted.

Sorry, but that is simply incorrect, on many levels. Virtual environments are the fundamental way of setting up a Python project, whether or not you use uv, which creates and manages them for you . And these virtual environments can freely either use or not use the system environment, whether or not you use uv to create them. It's literally a single-line difference in the `pyvenv.cfg` file, which is a standard requir…

This is more or less the thinking that got us into the mess Python packaging is. I, as a user, do not care whatsoever about any of this. At all. If you're explaining "virtual environments", you've lost the plot. Compiled languages got this right. The dev creates a binary and I as a user simply run it. That's it. That's the holy grail. It's good to see at last someone in the Python space got their ducks in a row and w…

This is why I ditched Python years ago for Go. I cross-compile my program binary to every OS + CPU combination then just curl the binary to the server and run it. Done. Life is much better. I encourage others to do the same. Python is a waste of time

Re: How uv got so fast

#462

Post by markkitti »

skywhopper wrote: post #32

This is great to read because it validates my impression that Python packaging has always been a tremendous overengineered mess. Glad to see someone finally realized you just need a simple standard metadata file per package.

"overengineered" is not the term I would use to describe Python packaging. I would say it is "under-engineered". As in, "Why engineer a configuration file when you can just do it in code?".

This tendency towards what initially seems like the "simple" solution pervades the Python ecosystem and often requires complex engineering to work around later.

Re: How uv got so fast

#463

Post by dent9 »

zahlman wrote: post #265
112233 wrote: post #257

Earlier quoted context omitted.

Not many normal people want to install python. Instead, author of the software they are trying to use wants them to install python. So they follow readme, download windows installer as you say, pip this pipx, pipx that conda, conda this requirements.txt, and five minutes later they have magic error telling that tensorflow version they are installing is not compatible with pytorch version they are installing or some s…

Scenarios like that are simply not realistic. Besides which, multiple solutions exist for bundling Python with an application.

"not realistic"? Lmao tell me you've never used Python without telling me you've never used Python. This kind of situation is so ubiquitous they've even got an xkcd comic for it https://xkcd.com/1987/

Re: How uv got so fast

#464

Post by dent9 »

jacquesm wrote: post #415
zahlman wrote: post #395

Earlier quoted context omitted.

> Scenarios like that occur daily. I do quite a bit of software development and whenever I come across something that really needs python I mentally prepare for a day of battle with the various (all subtly broken) package managers, dependency hell and circular nonsense to the point that I am also ready to give up on it after a day of trying. Please name a set of common packages that causes this problem reliably.

You're getting a bit boring, and are not arguing in good faith. "Reliably"... as per your definition I guess. You have now made 60(!!!) comments in this thread questioning everything and everybody without ever once accepting that other people's experiences do not necessarily have to match your own. If you did some reading rather than just writing you'd have seen that I gave a very specific example right in this threa…

Imagine telling 60 different people "you're wrong and I'm right" without realizing that it's actually you who is wrong

Re: How uv got so fast

#465

Post by dent9 »

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?

Eh conda was already doing all this stuff and its shipped in a self extracting .sh file and written largely in Python itself (at least it used to be lol)

Re: How uv got so fast

#466

Post by chrislusf »

weitendorf wrote: post #316
codeflo wrote: post #269

Earlier quoted context omitted.

That's no longer as true as it once was. I get the feeling that quite a few people would consider "benevolent dictator for life" an outdated model for open source communities. For better or worse, there's a lot of push to transition popular projects towards being led by committee. Results are mixed (literally: I see both successes and failures), but that doesn't seem to have any effect on the trend.

Only a very, very small fraction of open source projects get to the point where they legitimately need committees and working groups and maintainer politics/drama. > quite a few people would consider "benevolent dictator for life" an outdated model for open source communities. I think what most people dislike are rugpulls and when commercial interests override what contributors/users/maintainers are trying to get out…

I work on SeaweedFS. It is not backed by any greedy VC. So no urgency to make a large profit from the open source community.

Re: How uv got so fast

#467

Post by TeamDman »

webstrand wrote: post #446
SAI_Peregrinus wrote: post #367

Earlier quoted context omitted.

Paths are hard because they usually look like printable text, but don't have to be text. POSIX filenames are octet strings not containing 0x2F or 0x00. They aren't required to contain any "printable" characters, or even be valid text in any particular encoding. Most of the Rust stdlib you're thinking of is for handling text strings, but paths aren't text strings . Python also has the same split between Pathlib paths…

Yeah, the issue is that there are no utilities for manipulating OsStrings, like for splitting, regex matching, or formatting OsStrings/Paths. For instance the popular `fd` utility can't actually see files containing malformed utf-8, so you can hide files from system administrators naively using those tools by just adding invalid utf-8. touch $'example\xff.txt' fd 'example.*txt' // not found fd -F $'example\xff.txt' /…

I found https://docs.rs/bstr/latest/bstr/#file-paths-and-os-strings to be useful

Re: How uv got so fast

#468

Post by firesteelrain »

Mawr wrote: post #419
firesteelrain wrote: post #293

Earlier quoted context omitted.

Lack of stronger trust controls are part of the larger issue with npm. Pip, Maven and Go are not immune either but they do things structurally better to shift the problem. Go: Enforces global, append-only integrity via a checksum database and version immutability; once a module version exists, its contents cannot be silently altered without detection, shifting attacks away from artifact substitution toward “publish a…

For Go, there are more impactful features: minimal version selection and the culture of fewer, but larger dependencies. Your average Go project likely has 10x fewer deps than a JS project. Those deps will not get auto-updated to their latest versions either. Much lower attack surface area.

Agreed that fewer deps helps, but that’s largely downstream of Go’s mechanics. Minimal version selection annd immutability make churn abnormal, so graphs stay small. In JS ecosystems, churn is the default, so fan-out explodes.
Post reply on HN