Resolve ModuleNotFoundError: No module named 'pandas' in FastAPI/uvicorn on Raspberry Pi by aligning your venv and pip installs

Fix pandas ModuleNotFoundError on Raspberry Pi when running FastAPI/uvicorn: activate the correct venv, use python -m pip, reinstall requirements if needed.

Running a FastAPI service with uvicorn and multiprocessing on a Raspberry Pi can surface a deceptively simple error: ModuleNotFoundError: No module named 'pandas'. The project uses a dedicated virtual environment, requirements list includes pandas, and yet the import fails when uvicorn loads the application module. The issue usually isn’t in pandas itself or in your code, but in where the package was installed and which Python interpreter is actually running your processes.

Minimal reproduction from the service path

The failure is triggered when uvicorn imports the application module. In this case, the import line is enough to make it crash:

# src/services/ALS_back.py
import pandas as pnd

And the service is started from a function that hands off to uvicorn. The essence of the call path looks like this:

# main.py
import uvicorn

def start_backend(port_num):
    uvicorn.run("src.services.ALS_back:app", host="0.0.0.0", port=port_num, reload=False)

When uvicorn reaches the module import, it raises ModuleNotFoundError for pandas.

What actually goes wrong

The stack trace shows the interpreter loading packages from the project’s .venv. At the same time, the pip installation path points to /home/rpi/.local/lib/python3.9/site-packages, which is outside that venv. That mismatch strongly suggests packages were installed with the system pip rather than the virtual environment’s pip. If your launcher script starts Python without first activating the project’s .venv, subprocesses and uvicorn workers will inherit the wrong interpreter, and the import fails even though pandas is present elsewhere on disk.

Fix: install inside the venv you actually run

The reliable way to align installation and runtime is to activate the virtual environment before doing anything, upgrade the build tooling, and install requirements via the interpreter in that environment. From the project root:

cd /home/rpi/Desktop/als-v4
. .venv/bin/activate
python -m pip install --upgrade pip setuptools wheel
python -m pip install -r requirements-rpi.txt

Once that completes, confirm the packages resolve from the active environment:

python -c "import pandas; print(pandas.__version__)"
python -c "import numpy; print(numpy.__version__)"

If you start the app via a wrapper script (for example, alsv4), make sure it activates .venv before invoking Python or uvicorn so that all processes run under the same interpreter.

When a clean slate is the fastest route

If you’ve previously mixed system and venv installations and the steps above still don’t take effect, recreating the environment can be faster than debugging the residue. Removing the existing .venv, creating a new one, and reinstalling requirements restored the expected behavior for the same setup.

Why this matters on Raspberry Pi and similar setups

Tools like uvicorn and multiprocessing rely on the environment that launches them. If installation happens outside the venv, but the runtime points at the venv (or vice versa), you will get import errors despite having the package installed somewhere on the machine. Keeping installation and execution strictly within the same .venv avoids these class of failures and makes your deployment predictable.

Summary and practical advice

Activate the project’s .venv before installing anything and before starting the app. Use python -m pip to tie pip to the currently active interpreter. Install requirements-rpi.txt inside that venv. Verify versions with quick import checks. If problems persist from earlier inconsistencies, recreate the venv and reinstall. Finally, ensure your launcher script enables the environment before spawning uvicorn or any worker processes so every component resolves imports from the same place.