Sidebar Programming

Python Environments Cheat Sheet

Sidebar

Programming · Python Environments Cheat Sheet

Creating, activating, and safely tearing down a Python virtual environment — using the built-in venv module, no extra tools required.

Why Bother With One at All?

IsolationEach project gets its own private set of installed packages
No version clashesProject A can use Django 4 while Project B uses Django 5
A clean system PythonNothing you install for a project can break other tools on your machine
ReproducibilityA pinned package list lets anyone rebuild the exact same setup

Creating One

python -m venv myenvCreates a folder named myenv holding its own interpreter
python3 -m venv myenvUse this instead on macOS/Linux if python isn't aliased
Where to put itInside the project folder itself — commonly named venv or .venv

Activating

myenv\Scripts\activate.batWindows, Command Prompt
myenv\Scripts\Activate.ps1Windows, PowerShell (see Troubleshooting if this fails)
source myenv/bin/activatemacOS / Linux, bash or zsh
(myenv)The prompt prefix that confirms activation actually worked

Deactivating

deactivateThe exact same command on every platform — no arguments needed
where python / which pythonConfirms which interpreter is actually active right now

Installing & Freezing Packages

pip install requestsInstalls only into the currently active environment
pip freeze > requirements.txtSnapshots exact installed versions
pip install -r requirements.txtRecreates that exact same package set elsewhere
python -m pip install --upgrade pipA new venv often ships with an outdated bundled pip

Safely Deleting a Venv

deactivateStep 1 — leave it before deleting it
rmdir /s /q myenvWindows, Command Prompt
Remove-Item -Recurse -Force myenvWindows, PowerShell
rm -rf myenvmacOS / Linux
It's just a folderDeleting it never touches your actual project source files

Troubleshooting

"running scripts is disabled"PowerShell only — see the fix below
Packages installing "globally"You forgot to activate — check for the (myenv) prefix
Wrong Python version inside itDelete it and recreate with the correct interpreter, e.g. py -3.11 -m venv myenv
Old/broken pip errorspython -m pip install --upgrade pip while activated

Good Habits

.gitignoreAdd your venv folder name — never commit it to version control
requirements.txtCommit this instead, so the environment itself is always reproducible
One venv per projectDon't reuse a single environment across unrelated projects
Created it in the wrong folder, or with the wrong name? Delete it — don't try to move or rename it
A venv's own activation scripts and its pyvenv.cfg file have the absolute path to where it was created baked directly into them. Move the folder or rename it and those paths silently stop pointing anywhere real — activation can break in ways that are confusing to debug. Python's own official documentation is explicit about this: if you need a venv somewhere else, delete the misplaced one and run python -m venv again in the right location under the right name. It only takes a few seconds to recreate, and deleting it is completely safe — a venv holds nothing but installed packages and a copy of the interpreter, never your actual project code.
Fixing the PowerShell "running scripts is disabled" error
Run Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser once, in PowerShell. This only relaxes the policy for locally-created scripts under your own user account — it doesn't touch the whole system, and it isn't Python-specific. Using Command Prompt instead of PowerShell sidesteps the issue entirely, since cmd.exe doesn't block script execution this way.