←back to thread

Switching Pip to Uv in a Dockerized Flask / Django App

(nickjanetakis.com)
264 points tosh | 3 comments | 24 Jun 25 09:46 UTC | HN request time: 0s | source
Show context
ericfrederich ◴[24 Jun 25 12:39 UTC] No.44365535[source]▶
I am totally against Python tooling being written in a language other than Python. I get that C extensions exist and for the most part Python is synonymous with CPython.

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.

replies(20): >>44365585 #>>44365591 #>>44365607 #>>44365639 #>>44365650 #>>44365687 #>>44365703 #>>44365710 #>>44365785 #>>44365790 #>>44365821 #>>44365825 #>>44366008 #>>44366363 #>>44366783 #>>44366848 #>>44366923 #>>44367425 #>>44368861 #>>44373711 #
nchmy ◴[24 Jun 25 12:47 UTC] No.44365607[source]▶
What, exactly, is your objection to using rust (or any non-python/C language) for python tooling? You didn't actually give any reasons
replies(1): >>44365690 #
jftuga ◴[24 Jun 25 12:55 UTC] No.44365690[source]▶
I believe he alluded to it here...

"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."

replies(1): >>44365850 #
ericfrederich ◴[24 Jun 25 13:11 UTC] No.44365850[source]▶
Correct. There better be a damn good reason to add another language to the ecosystem other than it's that particular developer's new favorite language.

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

replies(3): >>44365994 #>>44366018 #>>44366097 #
nyzs ◴[24 Jun 25 13:24 UTC] No.44365994[source]▶
speed
replies(1): >>44366208 #
ericfrederich ◴[24 Jun 25 13:45 UTC] No.44366208[source]▶
I don't see any meaningful speedup. The 10x claims are not reproducible. He's also comparing it to the much older style of requirements.txt projects and not a poetry project with a lockfile.

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.

replies(2): >>44366502 #>>44366918 #
nchmy ◴[24 Jun 25 14:14 UTC] No.44366502[source]▶
You must be holding it wrong, because everyone else raves about uv
replies(1): >>44367974 #
1. cpburns2009 ◴[24 Jun 25 16:32 UTC] No.44367974[source]▶
Usually uv pip is only about x2 as fast as regular pip for me. Occasionally I'll have some combination of dependencies that will cause pip to take 2-5 minutes to resolve that uv will handle in 10-20 seconds.
replies(1): >>44368717 #
2. nchmy ◴[24 Jun 25 17:40 UTC] No.44368717[source]▶
They said "no meaningful speedup". 2x is meaningful
replies(1): >>44370206 #
3. cpburns2009 ◴[24 Jun 25 19:41 UTC] No.44370206[source]▶
The impact of a 2x speedup is relative. For a quick test on one of my projects it's 10 seconds with pip and 4 seconds with uv. That's roughly in line with my previous testing. It's a nice minor speedup on average. It really shines when pip does some non-optimal resolving in the background that takes a minute or more.