Python virtual environments — isolate dependencies per project

Why virtual environments?

Python projects pull in libraries from PyPI. Without isolation, upgrading package A for one project can silently break package B on your machine. A virtual environment gives each project its own site-packages directory and its own interpreter symlink chain.

Create a venv

From your project folder (terminal — not inside the browser IDE):

# macOS / Linux
python3 -m venv .venv

# Windows (cmd)
py -m venv .venv

Activate

# macOS / Linux (bash/zsh)
source .venv/bin/activate

# Windows PowerShell
.\.venv\Scripts\Activate.ps1

# Windows cmd.exe
.\.venv\Scripts\activate.bat

After activation, python and pip commands refer to the environment until you close the shell or run deactivate.

Install dependencies

pip install --upgrade pip
pip install requests

Verify inside Python

The snippet bundled with this article prints which interpreter executes your code — useful after activating a new environment. You should see a path ending with .venv/bin/python (Unix) or .venv\Scripts\python.exe (Windows).

Habits that save time

• Commit dependency snapshots with pip freeze > requirements.txt (or migrate to Poetry/uv later).
• Add .venv/ to your global gitignore template.
• Never reuse one mega-venv for unrelated repos — recreate per project.

Where the IDE fits

PythonSkillset’s browser runtime is isolated from your laptop — perfect for drills — while real deployments still rely on local or cloud venvs. Run the bundled editor sample to reinforce how sys.executable reflects the active interpreter.