Today I was working on setting up a new Python microservice. Even though my virtual environment seemed active, I hit two frustrating system environment quirks. Here is the breakdown to save you some time.
The Setup:
- OS Windows 11 (using MINGW64 Git Bash)
- Python Version: 3.13.5
- Target: FastAPI Microservice
Issue 1: pip install bypasses the .venv
Running standard pip instructions threw a warning stating that binaries were being deployed into global AppData directories. Running which pip confirmed it was pointing to my machine's primary global path.
The Fix: Don't rely on source .venv/Scripts/activate inside Git Bash if your system path variable configurations are sticky. Force execution by invoking the environment binary explicitly:
./.venv/Scripts/pip install fastapi uvicorn pydantic
Issue 2: ModuleNotFoundError: No module named 'app'
Once dependencies resolved, executing python app/main.py resulted in broken imports when trying to call internal structural directories.
The Fix: Execute your application script as a python module from the workspace root path instead of calling the script file directory paths directly:
./.venv/Scripts/python -m app.main
What are your favorite workarounds for handling Windows environment paths? Let me know below!
Top comments (1)
Great breakdown. Two extra tips: use python -m pip to avoid path mismatches, and pip install -e . to fix ModuleNotFoundError permanently. What’s your favourite environment fix?
Python #BackendDevelopment