Python Virtual Environments Finally Explained: venv, pip and Dependencies

A Python virtual environment isn't a tiny virtual machine.

It's a much simpler idea:

Give each project its own Python dependency context.

Imagine two projects:

Project A → package 1.x
Project B → package 2.x

If both projects depend on the same global Python installation, sooner or later those requirements can collide.

With virtual environments:

Project A → .venv → package 1.x
Project B → .venv → package 2.x

Each project gets its own dependency space.

Activating isn't magic

When you activate a virtual environment, you're not starting another operating system.

You're mainly changing which executables your shell finds first.

That's why this is such a useful diagnostic:

python -c "import sys; print(sys.executable)"

Instead of trusting the (.venv) label, ask Python which interpreter is actually running.

The same idea applies to pip

I prefer:

python -m pip install requests

because it makes the relationship explicit:

chosen Python
→ its pip
→ its packages

And the environment shouldn't be precious

A useful mental model is:

The environment is disposable. The recipe to rebuild it isn't.

That's why we usually keep things like:

source code
requirements.txt
.gitignore

in Git, but not the entire .venv directory.

I wrote a complete visual guide covering:

• venv
• activation
• pip
• direct vs transitive dependencies
• requirements.txt
• Git
• rebuilding environments
• common debugging mistakes

Full guide in Spanish:

https://tucodigocotidiano.yarumaltech.com/leer_guias/entornos-virtuales-y-dependencias-cada-proyecto-en-su-propia-burbuja/

One question for Python developers:

Can you delete your virtual environment today and rebuild it without guessing what was installed?