- 30 Oct, 2025 *
I encountered uv by accident. If I recall correctly, I was scrolling Hacker News, found a post on some Python code that looked like a good read, and learned of uv’s existence there.
This post by Dr. Emily Hunt does a great job of explaining uv in some detail, so I won’t reiterate the detail, suffice it to say that uv has given me the confidence to distribute Python code without thinking about how the next user is going to handle dependency management, or even different Python versions.
I understand that in a world of Docker, Podman, native macOS container runtimes and even pip and existing Python venv capabilities, that the above statement sounds a little silly. And yes, it probably is. Thing is, I don’t always wa…
- 30 Oct, 2025 *
I encountered uv by accident. If I recall correctly, I was scrolling Hacker News, found a post on some Python code that looked like a good read, and learned of uv’s existence there.
This post by Dr. Emily Hunt does a great job of explaining uv in some detail, so I won’t reiterate the detail, suffice it to say that uv has given me the confidence to distribute Python code without thinking about how the next user is going to handle dependency management, or even different Python versions.
I understand that in a world of Docker, Podman, native macOS container runtimes and even pip and existing Python venv capabilities, that the above statement sounds a little silly. And yes, it probably is. Thing is, I don’t always want to package or distribute my Python code. The stuff we write, we run in-house. We have complete access to the source code and a raft of CI pipelines that validate code before it is merged into the main line branch. Just being able to run it is good enough, from it’s location within the monorepo I maintain for my infosec tools. So the sheer fact that I can cd into the target directory and type uv run <app> <options> makes use of my code that much easier. If I write an app that has a Python dependency of 3.12, uv will install that for me before the script executes, based on the content of the .python-version file. Similarly, if there is an app that would benefit from reduced memory footprint or faster execution time from Python 3.13 or 3.14, I can request that minor version as a hard requirement, or uv pin something like Python 3.13.9, leaving it up to uv to handle the details. Alternatively, I can write something else and just tell uv to support anything from Python 3.9+.
Could I do the same thing in Docker? Yes. Do I want to? No. uv makes it so bloody easy to execute my code where I want it, i.e. on my own laptop, that I see no need to muck about with a Dockerfile packaging my app into an OS and allowing my obsession with detail to funnel me down a pipeline of reducing layers and properly annotating said Dockerfile with all of the stuff that lives in a properly formatted README already. If I want a colleague to run the same app, they can, regardless of what OS they happen to be on.
In my world view of system administration where every problem is a nail because the only tool I have is a hammer, uv is very much like crates for Rust. Isolated dependency management, but for a far older, far more nuanced programming language with vastly different versioning requirements based on the application of the application.
I ❤️ you, uv, for bringing a measure of sanity to a language that had started driving me bonkers before your arrival.