Deleting .venv safely

A virtual environment is disposable by design — but only if the lockfile names everything inside it. How to tell the difference for uv, Poetry, PDM, Pipenv and plain venv.

Updated 2026-09-20

A virtual environment is the most disposable directory in Python. It contains a copy of an interpreter, a site-packages full of downloaded wheels, and nothing you wrote. Recreating one is a single command. The only real question is whether that command gives you back what you had.

It depends entirely on what put the packages there

If the environment was built from a lockfile, it is fully described and safe to delete:

uv sync
          poetry install
          pdm sync
          pipenv install --deploy

Each reads uv.lock, poetry.lock, pdm.lock or Pipfile.lock and rebuilds the environment to exact versions. Delete .venv, run one of those, and you are where you were.

If the environment was built by hand — python -m venv .venv followed by a few pip install calls over several months — then nothing describes it. There is no file recording what is in there. Deleting it loses information, and the fact that requirements.txt exists is not evidence to the contrary, because requirements.txt is a wish list somebody maintains by hand and site-packages is the truth.

Check first: what is installed but not locked

Before deleting a hand-built environment, capture what is actually in it:

.venv/bin/python -m pip freeze > requirements-frozen.txt

On Windows: .venv\Scripts\python -m pip freeze. That file is now the description that did not exist, and the delete is reversible.

For a locked project, the equivalent check is to compare the two directly. This is the failure that bites in practice: somebody ran pip install pytest-anyio inside a uv-managed environment to try something, it worked, and it never made it into uv.lock. The environment now contains a package no lockfile mentions, and uv sync will not bring it back.

What "safe" means for the interpreter

The .venv also contains a Python. It is a copy or a symlink to a real interpreter installed elsewhere, and deleting the environment never touches that interpreter. Deleting .venv cannot break your Python installation. It can, however, break a .venv whose base interpreter has since been uninstalled — in which case the environment was already broken and you just had not run it lately.

Doing it across a machine

One .venv is a few hundred megabytes if it has NumPy and friends in it, and if you write Python you have dozens of them. dev-prune handles all five cases as separate adapters — uv, Poetry, PDM, Pipenv and plain venv — because they are distinguished by which lockfile sits next to the environment, and it runs the matching verification before it deletes anything:

devp init ~/Code
          devp run --dry-run

For plain venv, where no lockfile exists at all, it compares the installed distributions against pyproject.toml and refuses when it finds something it cannot account for. A refusal there is the tool telling you the truth about a directory you were about to lose.