[cqqxo4zV46cp]

Python is slow compared to Rust, obviously. Beyond that, pip is at this point carrying a bunch of legacy decisions because the ludicrously large number of hard left turns the Python packaging ecosystem has taken over the last 20 years.

Home Assistant is an absolute behemoth of a project, especially with regard to dependencies. Dependency resolution across a project of that size is nuts. There are probably few currently projects that’d see as big an improvement aa HA.

[eternityforest]

I'm not even sure how their packaging even works. Last I checked they had some kind of extra installer that works at runtime?

I have no idea how they keep version conflicts from breaking everything. Do integrations have isolation or something?

I wish python had a native way to have different libraries in the same project depend on different versions of a transitive dependency, seems like that would make a lot of stuff simpler with big projects.

[forrestthewoods]

Any specifics on what those legacy decisions are? I'm just curious. Have no idea. I'm a very casual Python user.

[mkesper]

If no hard versions are given, but only e.g. <= 2.1, pip will download EVERY SINGLE VERSION until 2.1 to look for metadata. That easily can take hours if it happens multiple times.

[bazzargh]

When testing previous versions of uv, I saw it do that too. But uv uses other tricks to speed things up: it downloads in parallel, it takes advantage of PEP-658 metadata (which doesn't need to download the package) and if that metadata is missing it will next try byte range requests to grab just the metadata of the wheel, and so on. pip was learning some of these tricks in recent releases too.

One problem we have is that support for any repository features beyond PEP-503 (the 'simple' html index) is limited or entirely missing in every repo implementation except warehouse - the software that powers pypi. So if you use artifactory, AWS codeartifact, sonatype nexus, etc, because you are running an internal repository, PEP-658 & PEP-691 support will be missing, and uv runs slower; you may not even have accept-ranges support. (and if you want dependabot, you need to have your repository implement parts of the 'warehouse json api' - https://warehouse.pypa.io/api-reference/json.html - for it to understand your internal packages)

I've been playing with https://github.com/simple-repository/simple-repository-serve... as a proxy to try to fix our internal servers to suck less; it's very small codebase and easy to change. Its internal caching implementation isn't great so I wrapped nginx round it too, using cache agressively and use stale-while-revalidate to reduce round trips, it made our artifactory less painful to use, even with pip.

[oblvious-earth]

pip will not do that, it will attempt to use the latest version under the user requirements, only if there is a conflict between two packages will it backtrack on old versions of a package, uv does exactly the same.

Further, if a package index supports PEP 658 metadata, pip will use that to resolve and not download the entire wheel.

uv does the same but adds extra optimizations, both clever ones that pip should probably adopt, and ones which involve assumptions that don't strictly comply to the standards, which pip should probably not adopt.