DEV Community

Ajit Kumar
Ajit Kumar

Posted on

When `venv` Lies: Debugging a Ghost Python 3.4 on Ubuntu

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

But Ubuntu reported:

sudo apt install python3
python3 is already the newest version (3.12.3)
Enter fullscreen mode Exit fullscreen mode

How can both be true?


Why This Happens

Linux resolves executables using $PATH.

Most systems have:

/usr/local/bin
/usr/bin
Enter fullscreen mode Exit fullscreen mode

If an old Python was manually compiled and installed into:

/usr/local/bin/python3
/usr/local/lib/python3.4
Enter fullscreen mode Exit fullscreen mode

It takes precedence over Ubuntu’s managed Python at:

/usr/bin/python3
Enter fullscreen mode Exit fullscreen mode

So when you run:

python3 -m venv venv
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

If it shows:

/usr/local/bin/python3
Enter fullscreen mode Exit fullscreen mode

That’s the problem.

Correct system Python should be:

/usr/bin/python3
Enter fullscreen mode Exit fullscreen mode

2️⃣ Verify Version Explicitly

python3 --version
/usr/bin/python3 --version
Enter fullscreen mode Exit fullscreen mode

If they differ, you have multiple Python installations.


3️⃣ Check SSL Module

python3 -c "import ssl"
Enter fullscreen mode Exit fullscreen mode

If it throws:

ImportError: No module named '_ssl'
Enter fullscreen mode Exit fullscreen mode

Your interpreter is broken or outdated.


4️⃣ Inspect Virtual Environment

Inside venv:

python --version
which python
which pip
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Step 2 — Use Explicit System Python

Never rely on ambiguous python3.

/usr/bin/python3 -m venv venv
source venv/bin/activate
Enter fullscreen mode Exit fullscreen mode

Step 3 — Verify Immediately

python --version
which python
which pip
Enter fullscreen mode Exit fullscreen mode

Expected:

Python 3.12.3
.../venv/bin/python
.../venv/bin/pip
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Now verify:

which python3
python3 --version
Enter fullscreen mode Exit fullscreen mode

Should resolve to:

/usr/bin/python3
Python 3.12.3
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

3. Prefer explicit paths in production

/usr/bin/python3 -m venv venv
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Project virtual environment:

venv → created from 3.12
pip → inside venv
Enter fullscreen mode Exit fullscreen mode

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)