←back to thread

Switching Pip to Uv in a Dockerized Flask / Django App

(nickjanetakis.com)
265 points tosh | 4 comments | 24 Jun 25 09:46 UTC | HN request time: 0.687s | 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 #
moolcool ◴[24 Jun 25 12:44 UTC] No.44365585[source]▶
> I am totally against Python tooling being written in a language other than Python

I will be out enjoying the sunshine while you are waiting for your Pylint execution to finish

replies(2): >>44365642 #>>44366217 #
1. carlhjerpe ◴[24 Jun 25 13:45 UTC] No.44366217[source]▶
Linting and type checking are very CPU intensive tasks so I would excuse anyone implementing those types of tools in $LANG where using all CPU juice matters.

I can't help but think uv is fast not because it's written in Rust but because it's a fast reimplementation. Dependency solving in the average Python project is hardly computationally expensive, it's just downloading and unpacking packages with a "global" package cache. I don't see why uv couldn't have been implemented in Python and be 95% as fast.

Edit: Except implementing uv in Python requires shipping a Python interpreter kinda defeating some of it's purpose of being a package manager able to install Python as well.

replies(2): >>44366916 #>>44378574 #
2. nonethewiser ◴[24 Jun 25 14:52 UTC] No.44366916[source]▶
You also have to factor in startup time and concurrency. Caching an SAT solvers can't get python to 95% of uv.
3. Daishiman ◴[25 Jun 25 15:42 UTC] No.44378574[source]▶
Nope, this is totally an area where using Rust makes sense and is just _fast_. The fact that Rust has concurrency primitives that are easy to use helps tons too.
replies(1): >>44379356 #
4. carlhjerpe ◴[25 Jun 25 16:48 UTC] No.44379356[source]▶
I still don't get it, uv is checking if dependencies exist on disk, if they do it creates a link from the cache to your environment, it's a stat syscall and a hardlink syscall in the best of worlds (after solving dependency versions but that should already be done in a lockfile).

Interpreter startup time is hardly significant once in one invocation to set up your environment.

What makes Rust faster for downloading and unpacking dependencies. Considering how slow pip is and how fast uv is (100s of X) it seems naive to attribute it to the language.