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

Source: Dev.to

Background

Virtual environments are supposed to isolate your project.
When a venv silently uses an ancient Python interpreter, everything can break.

Symptoms

python3 -m venv venv
source venv/bin/activate

• pip is missing inside the venv
• ensurepip fails with SSL errors
• get-pip.py refuses to run
• pip freeze shows nothing
• Importing ssl fails

Critical clue:

python3 --version
# Python 3.4.10

Yet Ubuntu reports:

sudo apt install python3
# python3 is already the newest version (3.12.3)

Diagnosis

PATH precedence

Linux resolves executables using $PATH. Typical order:

/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 will shadow the system‑managed Python at /usr/bin/python3.

Running:

python3 -m venv venv

therefore creates a virtual environment with Python 3.4, not 3.12.
Python 3.4 is end‑of‑life (2019), lacks modern SSL support, cannot run current pip, and is incompatible with today’s tooling.

Check which interpreter is being used:

which python3
# /usr/local/bin/python3   ← problem

The correct system interpreter should be:

which python3
# /usr/bin/python3

If they differ, you have multiple installations.

Test SSL support:

python3 -c "import ssl"
# ImportError: No module named '_ssl'

Inside the venv:

python --version
which python
which pip

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

Why venv didn’t protect you

venv simply clones the interpreter used to create it:

pythonX -m venv venv

If pythonX points to an outdated binary, the resulting environment inherits those problems. “Garbage in → garbage out.”

Fix

1. Remove the obsolete interpreter

   sudo rm /usr/local/bin/python3
   sudo rm /usr/local/bin/python
   sudo rm -rf /usr/local/lib/python3.4
   hash -r   # clear command hash cache

2. Verify the system Python

   which python3
   # /usr/bin/python3
   python3 --version
   # Python 3.12.3

3. Recreate the virtual environment using the correct interpreter

   /usr/bin/python3 -m venv venv
   source venv/bin/activate

4. Confirm the environment

   python --version
   # Python 3.12.3
   which python
   # .../venv/bin/python
   which pip
   # .../venv/bin/pip

Now ssl works, pip installs packages, and the environment is reproducible.

Takeaway

The issue is subtle because the system appears to work until you encounter SSL, pip, or dependency errors. When debugging Python environments on Linux:

• Always verify the interpreter path (which python3, python3 --version) before blaming pip, venv, or Ubuntu.
• Most environment problems are actually PATH problems in disguise.