Python Virtual Environment: venv, virtualenv, and the Right Defaults

A Python virtual environment is python -m venv .venv in your project directory, then .venv\Scripts\activate (Windows) or source .venv/bin/activate (macOS/Linux). The built-in venv module has shipped with Python since 3.3 - the team that has Python 3.3+ has zero excuse to install dependencies globally. The team that uses virtualenv instead gets faster environment creation and better backwards compatibility. The team that uses Poetry gets a full dependency and packaging workflow on top.

Table of contents

• The venv command
• Why virtual environments
• venv vs virtualenv
• The requirements.txt
• Common pitfalls
• Workflow tools: Poetry, uv, pipenv
• FAQ

The venv command

Create and activate:

python -m venv .venv
source .venv/bin/activate    # macOS/Linux
.venv\Scripts\activate      # Windows PowerShell

Verify:

which python    # should point inside .venv/
pip --version

The official Python docs confirm venv ships with Python 3.3+. The team that runs Python 3.3+ has it - no install needed. The team that uses an older Python (rare in 2026) installs virtualenv instead via pip install virtualenv.

Why virtual environments

Without a virtual environment, pip install requests installs globally. Two projects with different requests versions conflict. The team’s CI fails because the dev machine has requests==2.31 but production needs 2.28. A virtual environment gives every project its own isolated site-packages/.

Real Python’s primer walks through this in detail - the core insight is that virtual environments solve the dependency-version problem, not the ‘isolation from the system’ problem (which docker solves better).

venv vs virtualenv

venv is built-in but slow. virtualenv (separate package, pypa.io) is 5-10x faster and supports older Pythons (2.7+).

The team that uses venv for a 5-second pip install doesn’t notice the speed difference. The team that creates dozens of environments in CI cares. The team that uses Poetry or uv gets both speed and a workflow tool on top.

The requirements.txt

After activating:

pip freeze > requirements.txt

This captures exact versions. The team that uses pip freeze > requirements.txt and commits to git has reproducible builds. The team that uses pip freeze > requirements.txt with == versions can replay the exact environment anywhere.

For new projects, pyproject.toml (PEP 621) is the modern format. The team that uses pyproject.toml + pip install -e . has editable installs and one source of truth for project metadata.

Common pitfalls

1. Forgetting to activate - the install goes global. The fix: source .venv/bin/activate before any pip install.
2. Committing .venv/ to git - adds hundreds of MB. The fix: .venv/ in .gitignore.
3. Different Python versions - venv uses the Python that ran python -m venv. The fix: use python3.11 -m venv .venv to be explicit.
4. Activation not persisting - each shell needs its own activate. The fix: use direnv to auto-activate on cd.

The team that hits these once remembers the pattern for the rest of their career.

Workflow tools: Poetry, uv, pipenv

• Poetry: dependency + packaging + lock file. poetry add requests, poetry install. Lock file (poetry.lock) is deterministic.
• uv (Astral): 10-100x faster than pip. Drop-in replacement. Lock file via uv lock.
• pipenv: pip + virtualenv + Pipfile. Older, less momentum than Poetry/uv in 2026.

The team that picks Poetry has a full workflow. The team that picks uv has speed. The team that picks pip + venv has zero extra dependencies - fine for simple projects.

FAQ

Do I need virtualenv if I have Python 3.3+?

No - venv is built in and works for most cases. The team that uses virtualenv instead does so for speed or Python 2 support (rare in 2026).

Should I commit .venv/ to git?

No. Add .venv/ to .gitignore and commit requirements.txt (or pyproject.toml + poetry.lock). The team that commits .venv/ has a bloated repo with platform-specific binaries.

What’s the difference between venv and virtualenv?

venv is in the Python stdlib (Python 3.3+). virtualenv is a separate package that supports older Pythons and is faster. The team that has Python 3.10+ doesn’t need virtualenv.

How do I activate a venv in a shell script?

Source it: source .venv/bin/activate (bash) or .venv\Scripts\activate (PowerShell). The activate script sets PATH and VIRTUAL_ENV environment variables for the current shell.

Can I move a venv to another machine?

Not directly - the binaries are platform-specific. The fix: pip freeze > requirements.txt on the source, then pip install -r requirements.txt on the target. The team that uses Poetry’s poetry export or uv’s uv pip compile produces the same artifact.

If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.

Useful related references:

• Python Environment Variables
• Change Python Version
• Services/Python