←back to thread

Switching Pip to Uv in a Dockerized Flask / Django App

(nickjanetakis.com)
264 points tosh | 5 comments | 24 Jun 25 09:46 UTC | HN request time: 0.909s | 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 #
1. guardian5x ◴[24 Jun 25 12:55 UTC] No.44365687[source]▶
you say "I'm against it creeping into an existing eco-system for no reason.", while you ignore that there is at least one good reason: A lot better performance.
replies(2): >>44366151 #>>44367828 #
2. ericfrederich ◴[24 Jun 25 13:39 UTC] No.44366151[source]▶
The 10x performance wasn't mentioned in the article at all except the title.

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.

replies(1): >>44368382 #
3. cjaybo ◴[24 Jun 25 16:19 UTC] No.44367828[source]▶
Better performance than C? This is news to me
replies(1): >>44370068 #
4. mixmastamyk ◴[24 Jun 25 17:07 UTC] No.44368382[source]▶
I personally don’t care about the performance:

https://news.ycombinator.com/item?id=44359183

I agree it would be better if it was in Python but pypa did not step up, for decades! On the other hand, it is not powershell or ruby, it is a single deployed executable that works. I find that acceptable if not perfect.

5. kibwen ◴[24 Jun 25 19:32 UTC] No.44370068[source]▶
There are cases where single-threaded Rust and C are faster than each other, though usually only by single-digit percentages. But Rust is so much easier to parallelize than C that it isn't even funny.