> Ignoring requires-python upper bounds. When a package says it requires pythonErm, isn't this a bit bad?
How uv got so fast
271–280 of 468 posts
Re: How uv got so fast
#272Earlier quoted context omitted.
> has simply not read and understood Contemporary Python Development 101. They haven't. At the end of the day, they just want their program to work. You and I can design a utopian packaging system, but the physics PhD with a hand-me-down windows laptop and access to her university's Linux research cluster don't care about python other than it has a PITA library situation that UV addresses.
If they are not developers, it's the developer's responsibility to fix that. The developers have many options available for this.
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 their current problem, even if it could save them a lot of time in the long run. (Even though I find the situation frustration, I can't say I don't relate, given that I feel the same way about LaTeX.)
Re: How uv got so fast
#273> Ignoring requires-python upper bounds. When a package says it requires python Erm, isn't this a bit bad?
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
Re: How uv got so fast
#274The 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…
Note that the advantages of Rust are not just execution speed: it's also a good language for expressing one's thoughts, and thus makes it easier to find and unlock the algorithmic speedups that really increase speed.
But yeah. Python packaging has been dumb for decades and successive Python package managers recapitulated the same idiocies over and over. Anyone who had used both Python and a serious programming language knew it, the problem was getting anyone to do anything about it. I can't help thinking that maybe the main reason using Rust worked is that it forced anyone who wanted to contribute to it to experience what using a language with a non-awful package manager is like.
Re: How uv got so fast
#275Earlier quoted context omitted.
numpy would like a word
I think I understand what you're getting at, but I really think "Explicit is better than implicit" here.
> This would never work in a FOSS world because the project will be stuck in endless planning as everyone will have an opinion on how it should be done and nothing will actually get done.
numpy is the the de-facto foundation for data science in python, which is one of the main reasons, if not the main reason, why people use python
it's FOSS
and it "actually got done"
Re: How uv got so fast
#276Our next trick, getting people to stop writing code (so we can stop writing python)
Re: How uv got so fast
#277Earlier quoted context omitted.
I have reached a point where any AI smell (of which this articles has many) makes me want to exit immediately. It feels tortuous to my reading sensibilities. I blame fixed AI system prompts - they forcibly collapse all inputs into the same output space. Truly disappointing that OpenAI et all have no desire to change this before everything on the internet sounds the same forever.
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 definitely partially solved by extensive custom prompting, as evidenced by sibling comments. But that’s a lot of effort for normal users and not a panacea either. I’d rather AI companies introduce noise/randomness themselves to solve this at scale.
Re: How uv got so fast
#278Earlier quoted context omitted.
Linux systems commonly already provide an outdated system Python you don’t want to use, and it can’t be used to create a venv of a version you want to use. A single Python version for the entire system fundamentally doesn’t work for many people thanks to shitty compat story in the vast ecosystem. Even languages with great compat story are moving to support multi-toolchains natively. For instance, go 1.22 on Ubuntu 24…
> Linux systems commonly already provide an outdated system Python you don’t want to use Even with LTS Ubuntu updated only at EOL, Python will not be EOL most of the time. > A single Python version for the entire system fundamentally doesn’t work for many people thanks to shitty compat story in the vast ecosystem. My experience has been radically different. Everyone is trying their hardest to provide wheels for a wid…
Sure. You do a source install every time you require a python version newer than system python.
I'll be using uv for that though, as I'll be using it for its superior package management anyway.
Re: How uv got so fast
#279Earlier quoted context omitted.
> Isn't assigning out what all made things fast presumptive without benchmarks? We also have the benchmark of "pip now vs. pip years ago". That has to be controlled for pip version and Python version, but the former hasn't seen a lot of changes that are relevant for most cases, as far as I can tell. > This also doesn't cover subtle things. Unsure if rkyv is being used to reduce the number of times that TOML is parsed…
> This is interesting in that I wouldn't expect that the typical resolution involves a particularly large quantity of TOML. I don't know the details of Python's resolution algorithm, but for Cargo (which is where epage is coming from) a lockfile (which is encoded in TOML) can be somewhat large-ish, maybe pushing 100 kilobytes (to the point where I'm curious if epage has benchmarked to see if lockfile parsing is notic…
But once you have a lock file there is no resolution needed, is there? It lists all needed libs and their versions. Given how toml is written, I imagine you can read it incrementally - once a lib section is parsed, you can download it in parallel, even if you didn't parse the whole file yet.
(not sure how uv does it, just guessing what can be done)
Re: How uv got so fast
#280Earlier quoted context omitted.
The author’ blog was on HN a few days ago as well for an article on SBOMs and Lockfiles. They’ve done a lot of work in the supply-chain security side and are clearly knowledgeable, and yet the blog post got similarly “fuzzified” by the LLM.
There are a handful of things in TFA that, while not outright false, are sloppy enough that I'd expect someone knowledgeable to know/explain better.
I didn't notice that - can you give some examples?