venv and pip

Different projects often depend on different versions of the same third-party libraries. Installing everything into the global system Python easily leads to version conflicts. venv is the virtual environment module built into Python 3.3+ — no extra installation needed — and combined with pip it lets you create an isolated dependency environment per project. It’s the most basic, zero-dependency solution available.

Creating and Using a Virtual Environment

# Create a virtual environment named .venv in the project directory
python -m venv .venv

# Activate it
source .venv/bin/activate      # Linux / macOS
.venv\Scripts\activate         # Windows (cmd)
.venv\Scripts\Activate.ps1     # Windows (PowerShell)

# Once activated, python / pip point at the interpreter inside the venv
python -V
which python   # Linux/macOS — confirm the path points into .venv

# Leave the virtual environment
deactivate

Once activated, the shell prompt usually gets a (.venv) prefix, indicating you’re inside the virtual environment. Anything installed with pip install only lands in this isolated directory — it never pollutes the system Python or other projects.

Managing Dependencies with pip

# Install a single package
pip install requests

# Install a specific version constraint
pip install "django>=4.2,<5.0"

# List installed packages
pip list

# Export the current environment's dependencies to requirements.txt
pip freeze > requirements.txt

# Install dependencies from requirements.txt in a new environment
pip install -r requirements.txt

# Upgrade / uninstall
pip install --upgrade requests
pip uninstall requests

requirements.txt is the most universal dependency manifest format — nearly every Python project, CI pipeline, and Docker image build recognizes it, making it the standard way for teams to keep dependency versions in sync during collaboration and deployment.

Summary

The advantage of venv + pip is that it requires zero extra installation and ships with Python, making it a good fit for simple projects that don’t want to pull in another toolchain. The downside is that it has no real dependency-locking mechanism — requirements.txt is just a snapshot of “what happened to be installed at the time,” with no guarantee of reproducible installs — and its dependency resolution is slower than newer tools. If your project has complex dependencies and needs stronger reproducible-build guarantees, consider uv, covered later in this section.