How complex are the requirements for this project?
Readit Newsericfrederich commented on Switching Pip to Uv in a Dockerized Flask / Django App nickjanetakis.com/blog/sw... · Posted by u/tosh
ericfrederich commented on Switching Pip to Uv in a Dockerized Flask / Django App nickjanetakis.com/blog/sw... · Posted by u/tosh
speed
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.
ericfrederich commented on Switching Pip to Uv in a Dockerized Flask / Django App nickjanetakis.com/blog/sw... · Posted by u/tosh
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.
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.
ericfrederich commented on Switching Pip to Uv in a Dockerized Flask / Django App nickjanetakis.com/blog/sw... · Posted by u/tosh
According to the very link you provide, the sticking point was a dependency which does not use rust, and the maintainer probably being busy.
I updated a rust-implemented wheel to 3.13 compat myself and literally all that required was bumping pyo3 (which added support back in June) and adding the classifier. Afaik cryptography had no trouble either, iirc what they had to wait on was a 3.13 compatible cffi .
The PR which enabled 3.13 did have changes to Rust code.
ericfrederich commented on Switching Pip to Uv in a Dockerized Flask / Django App nickjanetakis.com/blog/sw... · Posted by u/tosh
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."
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?
ericfrederich commented on Switching Pip to Uv in a Dockerized Flask / Django App nickjanetakis.com/blog/sw... · Posted by u/tosh
2025 and python packaging and dependencies management is still a mess.
Yes, it's a mess (New: now with Rust!)
ericfrederich commented on Switching Pip to Uv in a Dockerized Flask / Django App nickjanetakis.com/blog/sw... · Posted by u/tosh
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.
ericfrederich commented on Oniux: Kernel-level Tor isolation for any Linux app blog.torproject.org/intro... · Posted by u/marcodiego
Irssi iirc used to default your username to your system username, so noobs would leak their given name by accident. After seeing that I changed my username in Linux to always be the most common username
I was talking more about you using HexChat with your preferred username "FooBar", but then when on Tor you want to be "SpamEggs". If you launch HexChat through oniux and it reads your config file, you might hit the login button before changing your name from FooBar to SpamEggs.
ericfrederich commented on Oniux: Kernel-level Tor isolation for any Linux app blog.torproject.org/intro... · Posted by u/marcodiego
They use hexchat as an example but do these processes run with the users configuration? Wouldn't this leak IRC usernames if you forget to change it.
... Or leak cookies if you launch a browser?
> Is there anything being done in uv that couldn't be done in Python?
Speed, at the very least.
You could just ignore uv and use whatever you want...
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?