Python venv activated but which python is still the system one

Activating a virtual environment only prepends its bin folder to PATH in that one shell. If which python still shows /usr/bin/python3, the activate step never took, you opened a new terminal, or another tool is picking a different interpreter.

What “activated” is supposed to do

A venv is just a folder (often .venv) with its own python, pip and a small activate script. Running that script puts the folder’s bin (or Scripts on Windows) at the front of PATH for the current shell and usually changes the prompt to (.venv). It does not change other terminals, background jobs, or the interpreter your editor already chose.

Prove which Python is running

which python; which python3; which pip
command -v python          # same idea, works in more shells
python -c "import sys; print(sys.executable)"
pip -V                     # shows which Python that pip belongs to
echo $VIRTUAL_ENV          # set when activate worked (Unix)
echo %VIRTUAL_ENV%         # Windows cmd

All three should point into the same .venv folder. If which python says /usr/bin/python3 while pip -V says .venv, or the other way round, you have a PATH / alias mismatch: installs go one place and your code runs another. Compare two pip freeze dumps in the text diff tool to see what each environment actually has.

How to activate on each platform

Typing activate alone only works if that script is already on PATH. source (or .) runs the file in the current shell so the PATH change sticks; running it as a normal program starts a child shell, changes PATH there, and throws the change away when it exits.

Common reasons it “doesn’t work”

• New terminal tab: activation is per shell. Run activate again, or configure your terminal profile / direnv with an .envrc that runs source .venv/bin/activate.
• Created with the wrong Python: always python3 -m venv .venv (or py -3.12 -m venv .venv on Windows). Recreate if you upgraded Python: delete the folder and make it again.
• Nested or leftover venvs: an outer activate plus an inner one leaves PATH confusing. deactivate until echo $VIRTUAL_ENV is empty, then activate the one you want.
• VS Code / Cursor: the status-bar interpreter (or Python: Select Interpreter) overrides the terminal. Pick .venv/bin/python. The terminal may still need activate for pip you type by hand.
• Shebang vs PATH: a script starting #!/usr/bin/python3 ignores your venv when you run ./app.py. Use #!/usr/bin/env python3 after activate, or run python app.py / the venv’s absolute path.
• Windows execution policy: Activate.ps1 blocked? Use activate.bat, or see running scripts is disabled.
• Windows py launcher: py can ignore the active venv and pick a global install. Prefer python after activate, or .venv\Scripts\python.exe.
• macOS Homebrew vs /usr/bin/python3: Apple’s stub and Homebrew’s python3 are different. Create the venv with the same binary you intend to run: /opt/homebrew/bin/python3 -m venv .venv.
• Aliases and functions: alias python=python3 or a shell function can shadow the venv. Check with type python / Get-Command python.

Related

Installed a package and still get No module named? The interpreter running the code isn’t the one pip wrote to: ModuleNotFoundError. On Ubuntu 24.04 / Debian 12 the reason you need a venv at all is externally-managed-environment. PowerShell blocking Activate.ps1: running scripts is disabled. · pip: Could not find a version

Questions

Published 5 November 2026.