April 2026 · 5 min read

I Used Pip for Years.
Poetry for Teams.
Then Uv Showed Up.

The quiet tool choice behind every Python project. The honest story of how mine changed.

Python Tooling AI Stack

If you write Python, you install packages. That's it. It should be boring.

But the tool you use to install those packages quietly shapes your whole day: how fast you move, how easy it is to share your work, and how often something breaks on a teammate's machine. I've been through three of them. I used pip for years. I moved to poetry when I started building with teams. And lately I've been using uv to scaffold new AI projects: a RAG pipeline with Supabase, a text-to-speech service, an image recognition demo. Here's what I've actually felt, not what the docs say.


Pip: The One You Already Know

Pip ships with Python. Every tutorial uses it. Every Docker image has it. You type pip install requests and you're moving. For learning, for scripts, for one-file tools, it's still the right answer.

The problem shows up later. Pip doesn't really remember the exact versions you used. You write a requirements.txt, you pin a few packages, you think you're safe. Then six months pass, a sub-dependency quietly bumps, and suddenly your code behaves differently. You have no clean way back to exactly the world you had before.

So pip is honest about what it is: a package installer. Not a project manager. Not a version locker. If you want those, you need something on top.

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

My rule: pip is fine for small scripts and notebooks. The moment a project has a name and a future, I want more.

Poetry: When Other People Show Up

Poetry was my answer for a long time. The switch happened the first time someone else cloned my repo and couldn't run it. That's when you realize "works on my machine" is a liability.

Poetry fixes that. It keeps a real lock file: the exact versions of every package, frozen in place. A new teammate runs poetry install and gets the same environment you have. No more "but which version of numpy did you have?"

It does other grown-up things too, in plain English: it separates dev tools (tests, linters) from production packages, so your shipped image doesn't carry extra baggage. It handles publishing to PyPI if you want to release a library. It talks to private package servers without much fuss.

[tool.poetry.dependencies]
python = "^3.11"
fastapi = "^0.110"

[tool.poetry.group.dev.dependencies]
pytest = "^8.0"
ruff  = "^0.3"

The cost is real. Poetry is slower than pip, especially when it resolves dependencies. It has its own way of doing things, which means a day or two of learning. And a few fast-moving AI libraries sometimes publish wheels that confuse it.

My rule: the moment a project has more than one person on it, poetry earns its keep.

Uv: The Surprise

Uv is the one that surprised me. I wasn't looking for a new tool. Pip and poetry were covering my life. Then I started using uv to scaffold new AI project templates. RAG with Supabase. TTS. Image recognition. And something felt off.

It was fast. Not a bit faster. A lot faster. Installs that took a minute in poetry finished in a few seconds. The first time it happened, I thought it had skipped a step.

Why it's different, in plain words: uv is written in Rust, not Python. That means it doesn't wait around while it figures things out. It installs your packages, manages your Python version (so you don't need pyenv on the side), and gives you a project file that looks a lot like poetry's. All in one tool.

Poetry feels like setting up a workshop. Uv feels like a sharp knife.

You can use uv two ways. If you like pip, type uv pip install requests and it behaves like pip, only much faster. If you want the full project mode, run uv init, then uv add requests, and you get a lockfile and a managed environment without any extra setup.

Honest catches: uv is younger than the other two. A handful of older packages still trip it up. The ecosystem around it (the tutorials, the Stack Overflow answers, the CI recipes) is still catching up to poetry's.

My rule: if I'm starting something new this week, I reach for uv first.

So Which One, When?

Here's how I think about it now:

The Quiet Truth

The best tool is the one your team will actually use the same way you do. A committed lock file in your repo beats any clever package manager sitting in your head. Pick one. Commit it. Move on to the real work.


Tooling is low-glamour. Nobody gets hired for picking uv over poetry. But the thirty seconds you save on every install, and the three hours you don't spend debugging a broken environment: those add up. Pick the one that fits the project in front of you, not the one winning the loudest argument online.

I'm still using all three. Just not for the same things anymore.