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:
-
pipdidn’t exist inside the venv -
ensurepipfailed with SSL errors -
get-pip.pyrefused to run -
pip freezeshowed 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.
Top comments (0)