`python -m venv` Is Still the Clean Default Because Global Installs Keep Creating Fake Mysteries

Why this still matters in 2026: Python tooling has improved, but a huge amount of avoidable confusion still comes from one old habit: installing project dependencies into the wrong interpreter.

What venv gives you

The Python documentation describes venv as creating lightweight virtual environments, each with its own independent packages installed in its site directories. That independence is the real value.

A virtual environment gives a project its own Python executable and dependency space. By default it is isolated from the base environment, which means packages you install there do not spill into unrelated projects.

This is not ceremony for its own sake. It is what prevents a dependency choice in one repo from quietly changing another repo’s behavior.

The clean default

Create an environment:

python3 -m venv .venv

Activate it on macOS or Linux:

source .venv/bin/activate

Then install packages normally:

pip install -r requirements.txt

That is still one of the most dependable baseline workflows in Python development.

Why global installs create fake mysteries

When packages live in the global interpreter, developers start seeing symptoms like:

1. one project works, another breaks
2. the version “should” be one thing but imports another
3. team members cannot reproduce each other’s results

These often feel like complex Python problems. They are frequently just environment-boundary problems.

venv makes the boundaries explicit.

Why .venv inside the project is a good convention

The Python docs note common conventions such as .venv or venv in the project directory. Keeping it local makes the environment easier to find, easier to recreate, and easier for editors to discover automatically.

It also reinforces the right mental model: this environment belongs to this project.

Why environments should be disposable

The docs make an important point: virtual environments are considered disposable. You should be able to delete and recreate them.

That is why you do not check them into Git, and it is why good Python workflows depend on declarative dependencies such as requirements.txt or other lock/metadata files. The environment is a build artifact of configuration, not a treasured snowflake.

A practical debugging benefit

If a dependency setup feels cursed, recreating the environment becomes a legitimate first-class move rather than a dramatic last resort:

rm -rf .venv
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

That is much cleaner than trying to mentally untangle a globally polluted interpreter.

Why this stays relevant even with newer Python tooling

Modern tools can wrap or enhance environment management, but the core value remains the same: isolation. Even if a team later adopts other tooling, understanding venv gives you a dependable baseline that works across many machines and projects without much ceremony.

That is what makes it a strong default. It may not be the fanciest layer in the ecosystem, but it is one of the clearest and most portable ones.

Final recommendation

If a Python project has dependencies, give it its own venv by default. Global installs still create too many fake mysteries, while isolated environments make package behavior much easier to reason about and reproduce.

Sources

• Python venv documentation