Virtual environments are supposed to isolate your project. But what happens when your venv quietly binds itself to a decade-old Python interpreter?

Here’s a real-world debugging story of how Python 3.4 hijacked a modern Ubuntu system running Python 3.12 — and how to diagnose and fix it correctly.

The Symptom

Everything looked normal:

python3 -m venv venv

source venv/bin/activate

But then:

• 
  pip didn’t exist inside the venv


• 
  ensurepip failed with SSL errors


• 
  get-pip.py refused to run


• 
  pip freeze showed nothing


• SSL module failed to import

Critical clue:

python3 --version

Python 3.4.10

But Ubuntu reported:

sudo apt install python3

python3 is already the newest version (3.12.3)

How can both be true?

Why This Happens

Linux resolves executables using $PATH.

Most systems have:

/usr/local/bin

/usr/bin

If an old Python was manually compiled and installed into:

/usr/local/bin/python3

/usr/local/lib/python3.4

It takes precedence over Ubuntu’s managed Python at:

/usr/bin/python3

So when you run:

python3 -m venv venv

You unknowingly create a virtual environment using Python 3.4 — not 3.12.

And since Python 3.4:

• Is end-of-life (2019)


• Lacks modern SSL support


• Cannot run modern pip


• Is incompatible with current tooling

Your venv becomes broken from the start.

How to Detect the Problem

1️⃣ Check Which Python Is Being Used

which python3

If it shows:

/usr/local/bin/python3

That’s the problem.

Correct system Python should be:

/usr/bin/python3

2️⃣ Verify Version Explicitly

python3 --version

/usr/bin/python3 --version

If they differ, you have multiple Python installations.

3️⃣ Check SSL Module

python3 -c "import ssl"

If it throws:

ImportError: No module named '_ssl'

Your interpreter is broken or outdated.

4️⃣ Inspect Virtual Environment

Inside venv:

python --version

which python

which pip

If version shows 3.4.x, your venv was created from the wrong interpreter.

Why venv Doesn’t Protect You

venv is not magic.

It simply clones the interpreter used to create it:

pythonX -m venv venv

If pythonX is wrong, your venv is wrong.

Garbage in → garbage out.

The Correct Fix

Step 1 — Delete the Broken Virtual Environment

deactivate

rm -rf venv

Step 2 — Use Explicit System Python

Never rely on ambiguous python3.

/usr/bin/python3 -m venv venv

source venv/bin/activate

Step 3 — Verify Immediately

python --version

which python

which pip

Expected:

Python 3.12.3

.../venv/bin/python

.../venv/bin/pip

Step 4 — Remove Old Python (If Safe)

If you confirm /usr/local/bin/python3 is obsolete:

sudo rm /usr/local/bin/python3

sudo rm /usr/local/bin/python

sudo rm -rf /usr/local/lib/python3.4

hash -r

Now verify:

which python3

python3 --version

Should resolve to:

/usr/bin/python3

Python 3.12.3

Key Lessons

1. venv uses whatever interpreter you give it

It does not automatically select the newest Python.

2. Always verify interpreter path

Before creating a venv:

which python3

python3 --version

3. Prefer explicit paths in production

/usr/bin/python3 -m venv venv

4. Old /usr/local installations often override system tools

Manual builds are invisible to apt.

Final State (Healthy Setup)

System Python:

/usr/bin/python3 → 3.12

Project virtual environment:

venv → created from 3.12

pip → inside venv

Now:

• SSL works


• pip works


• Modern packages install


• Environment is reproducible

Conclusion

This issue is subtle because nothing crashes immediately. The system appears to work — until you hit SSL, pip, or dependency errors.

When debugging Python environments on Linux:

Always verify the interpreter path before blaming pip, venv, or Ubuntu.

Most environment problems are PATH problems in disguise.