A virtual environment is an isolated Python installation for a single project, with its own independently-managed set of installed packages — the standard way to avoid version conflicts between projects.
python3 -m venv venv # creates a 'venv' folder with an isolated environment
# activate it:
source venv/bin/activate # macOS/Linux
venv\Scripts\activate # Windows
pip install requests # installs INTO the active virtual environment only
pip list # shows what's installed here
pip freeze > requirements.txt # save exact installed versions to a file
pip install -r requirements.txt # recreate the same environment elsewhere
deactivate # leave the virtual environment
Without a virtual environment, every pip install affects your single, system-wide Python installation — if Project A needs requests==2.20 and Project B needs requests==2.31, installing one breaks the other. A virtual environment gives each project its own private set of installed packages, completely isolated from the system Python and from other projects' environments.
requirements.txt (generated by pip freeze) records the exact package versions a project depends on, letting anyone else — a teammate, a deployment server, your future self — recreate the identical environment with pip install -r requirements.txt. Creating a virtual environment for every project, immediately, before installing anything, is one of the most important habits for avoiding painful, hard-to-diagnose dependency issues later. Newer, faster alternatives like uv and poetry build on the same underlying concept while adding dependency-resolution and project-management features.