Python virtualenv not activated or interpreter mismatch

Python code is using a system interpreter or wrong virtualenv instead of the activated one, causing module import failures or version mismatches.

python-virtualenv-not-activated medium confidence build python

Matched signals

  • activate: not found
  • source.*venv
  • /usr/bin/python.*No module named
  • venv/bin/activate
  • site-packages from system Python

Python virtualenv not activated or interpreter mismatch

What this failure means

Python code is using a system interpreter or wrong virtualenv instead of the activated one, causing module import failures or version mismatches.

Symptoms

Faultline looks for one or more of these log fragments:

activate: not found
source.*venv
/usr/bin/python.*No module named
venv/bin/activate
site-packages from system Python

Diagnosis

When a Python virtualenv is not activated or is deactivated mid-build, pip and modules are installed in the wrong location. Common causes:

  • The virtualenv activation step (e.g., source venv/bin/activate) was skipped or failed silently
  • The build runs multiple shell invocations without persisting the activation across steps
  • The script uses #!/usr/bin/env python which may resolve to the system interpreter, not the virtualenv one
  • GitHub Actions or other CI steps start with a fresh shell that needs re-activation

Symptoms include ModuleNotFoundError for packages that were installed, or import failures from the wrong Python version.

Fix steps

  1. Create and activate the virtualenv explicitly in your CI build script:

    python3 -m venv venv
    source venv/bin/activate  # On Windows: venv\Scripts\activate
    pip install -r requirements.txt
    python -m pytest
    
  2. If using GitHub Actions, use actions/setup-python to manage the virtualenv:

    - uses: actions/setup-python@v4
      with:
        python-version: '3.11'
       cache: 'pip'
    - run: pip install -r requirements.txt
    - run: python -m pytest
    
  3. If running multiple steps, either source the activation in each step or use a single shell script:

    - run: |
        source venv/bin/activate
        pip install -r requirements.txt
        python -m pytest
    
  4. Verify the correct Python interpreter is in use:

    which python3
    python3 --version
    

Validation

  • which python3 shows the path inside the virtualenv, not the system Python.
  • python3 -c "import sys; print(sys.prefix)" shows the virtualenv directory.
  • pip list shows the packages from requirements.txt.
  • Re-run the test or build command successfully.

Why it matters

Virtualenvs isolate project dependencies from the system Python and other projects. Using the wrong interpreter leads to missing modules, version conflicts, and non-deterministic behavior across machines.

Prevention

  • Always explicitly activate the virtualenv in CI steps.
  • Use python -m <module> instead of calling scripts directly to ensure the correct interpreter.
  • Test the build script locally before committing.
  • Document the Python version and virtualenv setup in README.md or .python-version.

Try it locally

python3 -m venv venv
source venv/bin/activate
pip list
which python3
source venv/bin/activate
python3 -c "import sys; print(sys.prefix)"

How Faultline detects it

Use faultline explain python-virtualenv-not-activated to see the full playbook.

faultline analyze build.log
faultline explain python-virtualenv-not-activated

Generated from playbooks/bundled/log/build/python-virtualenv-not-activated.yaml. Do not edit directly.

Try it on your own failed log

$ faultline analyze failed.log
Want this across every CI run? Faultline Teams tracks recurring failures across all your repos and surfaces patterns in a shared dashboard.