In an ecosystem where the primary implementation of the language is in C and nearly all native extensions are written in C do you really not know the answer to that?

I detailed this in another comment but pip (via requirements.txt): 8.1s, poetry: 3.7s, uv: 2.1s.

Not even 10x against pip and certainly not against poetry.

I watched the video and he does mention it going from 30s to 3s when switching from a requirements.txt approach to a uv based approach. No comparison was done against poetry.

I am unable to reproduce these results.

I just copied his dependencies from the pyproject.toml file into a new poetry project. I ran `poetry install` from within Docker (to avoid using my local cache) `docker run --rm -it -v `pwd`:/work python:3.13 /bin/bash` and it took 3.7s

I did the same with an empty repo and a requirements.txt file and it took 8.1s.

I also did through `uv` and it took 2.1s.

Better performance?, sure. A lot better performence?, I can't say that with the numbers I got. 10x performance?... absolutely not.

Also, this isn't a major part of anybody's workflow. Docker builds happen typically on release. Maybe when running tests during CI/CD after the majority of work has been done locally.

https://github.com/python-pendulum/pendulum/pull/871

Is there anything being done in uv that couldn't be done in Python?

I think 2 languages are enough, we don't need a 3rd one that nobody asked for.

I have nothing against Rust. If you want a new tool, go for it. If you want a re-write of an existing tool, go for it. I'm against it creeping into an existing eco-system for no reason.

A popular Python package called Pendulum went over 7 months without support for 3.13. I have to imagine this is because nobody in the Python community knew enough Rust to fix it. Had the native portion of Pendulum been written in C I would have fixed it myself.

https://github.com/python-pendulum/pendulum/issues/844

In my ideal world if someone wanted fast datetimes written in Rust (or any other language other than C) they'd write a proper library suitable for any language to consume over FFI.

So far this Rust stuff has left a bad taste in my mouth and I don't blame the Linux community for being resistant.

I especially hate how they've integrated CI/CD into the Git platforms.

I loathe the fact that Microsoft has tied their AI to their Git platform.

I want my CI/CD to be agnostic. I want my AI to be agnostic. I want my issues, MRs, comments, etc to be decentralized and come along for the ride when I clone a repo.

Specifically, pendulum hasn't released a wheel yet for 3.13 so it tried to build from source but it uses Rust and the Python docker image obviously doesn't have Rust installed.

Insane

Features should be developed and tested locally before any code is pushed to a CI system. Dependency resolution should happen once while the container is being built. Containers themselves shouldn't be installing anything on the fly it should be baked in exactly once per build.

I see that UV is bragging about being 10-100x faster than pip. In my experience the time spent in dependency resolution is dwarfed by the time making web requests and downloading packages.

Also, this isn't something that runs every time you run a Python script. It's ran once during installation of a Python package.