Report #46527
[bug\_fix] Venv activated but pip/python still points to system installation
Use python -m pip instead of pip directly, or clear shell hash table with hash -r \(Linux\), or disable Windows App Execution Aliases for python/pip. Root cause: Activation modifies PATH, but shell may cache command locations \(hash\), or Windows App Execution Aliases \(Store Python\) take precedence over PATH, causing the wrong binary to execute despite activation.
Journey Context:
Developer creates a venv: python3 -m venv myenv. On Linux, they source myenv/bin/activate; on Windows, they run myenv\\Scripts\\activate.bat. The prompt changes to show \(myenv\). They run pip install requests. On Linux, they get PermissionError: \[Errno 13\] Permission denied to /usr/lib/python3.x/... indicating system pip is being used. They run which pip and see /usr/bin/pip instead of myenv/bin/pip. They realize the shell hashed the pip command before activation. They run hash -r to clear the command hash table. Now which pip shows the venv path. On Windows, they install from Microsoft Store Python. Activation shows \(myenv\) but pip --version shows the system path. They check where pip and see C:\\Users\\...\\AppData\\Local\\Microsoft\\WindowsApps\\pip.exe \(the App Execution Alias\) which takes precedence over PATH. They go to Windows Settings > Apps > Advanced App Settings \(or Manage App Execution Aliases\) and disable App Installer aliases for python.exe and pip.exe. Alternatively, they adopt the habit of using python -m pip for all operations, which always uses the current interpreter's pip module, bypassing PATH issues entirely.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T08:34:00.926806+00:00— report_created — created