I have recently learned about uv and the uv workflow. Since then, I’ve been using uv a lot more, both for personal projects and at work!
uv is the best
My conclusion is: if your situation allows it, always try uv first. Then fall back on something else if that doesn’t work out.
While reading more about uv, I found these two articles:
- Production-ready Python Docker Containers with uv (Hynek Schlawack)
- A year of uv: pros, cons, and should you migrate (Bite code! | Substack)
What’s interesting, is that these both of these articles each link to older articles where they each extensively compared tools for Python dependency management.
- Python Application Dependency Management (Hynek Schlawack)
- Why not tell people to “simply” use pyenv, poetry, pipx or anaconda (Bite code! | Substack)
The articles reach similar conclusions, in that the existing tools can be useful but have limitations. However, both articles have been updated to have disclaimers at the top:
This article is really old.
If you want to see how I manage my dependencies since 2024, the short answer is uv, and the long answers are:
- Production-ready Python Docker Containers with uv
- and Python Project-Local Virtualenv Management Redux
Spoiler: Everything got pretty good.
- Python Application Dependency Management (Hynek Schlawack)
THIS ARTICLE HAS BEEN WRITTEN BEFORE UV EXISTED. UV SOLVES MOST OF THOSE PROBLEMS. YOU CAN TELL PEOPLE TO “SIMPLY” USE UV.
- Why not tell people to “simply” use pyenv, poetry, pipx or anaconda (Bite code! | Substack)
As far as I am aware, the authors were not inspired by each other. They both tried to solve the problems of Python dependency management, found the previous tools lacking, and now love uv.
My Opinion
I have personally not compared every single Python dependency management tool, but do give weight to the opinion of those who have. In the past, I have heard about tools like virtualenv, pyenev, poetry and others, and decided to simply stick with pip and venv. However, after hearing increasingly good things about uv, I decided to try it myself. I have now used it for several projects, both work and personal projects. My conclusion: it’s good.
I don’t know if I will be using uv for every project. As good as uv is, I am still sometimes hesitant to add a new build dependency. I also had some concerns about the venture-backed nature of uv (which I addressed in when writing about the Business Model in Next Generation Tooling for Developers).
At the same time, uv works really well and is even fun to use, so I’ll probably trend towards using it more often than not. The fact that the tool is open source and strives to conform to Python PEP standards also makes me feel comfortable using it. For example, uv works with pyproject.toml. In theory, I could replace uv with another tool in the future but still use the same file. I looked at what it takes to use pyproject.toml on its own and found this article: Python packages with pyproject.toml and nothing else | Simon Willison’s TILs. This shows me that it’s possible to work this way without using a tool like uv, however using uv makes things much easier!
Featured image by Point Blanq on Unsplash.
