Why we're keeping venv, for now

Every so often a tool gets fast enough that you wonder whether your boring choice has quietly become the wrong one. This month it was uv — Astral’s Rust-based installer — against the stdlib venv + pip + requirements.txt that every one of our agent repos runs on. I did the homework properly: multiple sources, primary docs, the lot. We’re staying on venv. The why is the part worth writing down.

Still the standard, not a relic

Worth saying plainly, because the internet implies otherwise: venv is not a deprecated path you’re clinging to. PyPA still lists venv and pip as the standard tools to create an environment and install into it. Our setup — six independent agent repos, each with its own .venv/, a shared agent-core pinned by commit SHA and installed editable for local dev — already gives us the isolation and reproducibility we need. Nothing here is on fire.

uv would genuinely fit our rules

This isn’t a “new tool bad” post. uv maps cleanly onto how we already pin everything:

uv pip compile            # exact-version locks, like pip-tools
uv add --rev <sha>        # a git dependency pinned to one commit
uv add --editable ../agent-core   # our local-dev shared framework
uv sync --locked          # CI gate that FAILS on a stale lock
uv lock --upgrade-package <name>  # bump one dependency, vetted, in isolation

It’s a documented drop-in — uv pip install mostly just works — and it sits at the table for PEP 751, the new standard lock format that mandates hashes. On the merits, it’s a yes.

So why not yet

Our dependency policy is the lens for everything: pin to an exact version or SHA, wait four weeks after a release, read the upstream issues, pip-audit clean before any bump, never chase latest. That lens applies to the tools too, not just what they install. venv and pip cost us zero new vendor and zero governance risk — they ship inside Python. uv is a single company’s product, and single-vendor tooling can be relicensed, redirected, or acquired — and there’s already chatter pointing that way.* That’s precisely the supply-chain signal our policy exists to catch. You don’t re-pour your build’s foundation the same season the ownership question opens.

A tool you can’t rip out cheaply isn’t a convenience — it’s a dependency. Judge it like one.

So here’s the parked idea, not a commitment: adopt uv later as a drop-in accelerator — uv venv, uv pip install, uv pip compile — while requirements.txt stays the source of truth and uv never becomes a runtime dependency. Pinned, vetted, replaceable in an afternoon. When the governance picture settles, that’s a clean afternoon’s win. Until then, boring keeps the keys.

---

* Rumor, not confirmed: the acquisition reports were unverified at the time of writing.