What's the difference between `venv`, `virtualenv`, `pipenv`, `poetry`, and `conda`?
Quick Answer
`venv` (built into the standard library) creates an isolated Python environment with its own `site-packages`, so project dependencies don't conflict across projects. `virtualenv` is a more feature-rich third-party predecessor to `venv`. `pipenv` and `poetry` add dependency *management* on top (a lockfile for reproducible installs, a single `pyproject.toml`/`Pipfile` combining dependency declaration and environment management) — `poetry` additionally handles packaging/publishing. `conda` is a separate ecosystem that manages both Python *and* non-Python system dependencies (C libraries, compilers), popular in data science.
Detailed Answer
The core problem all of these solve: dependency isolation
# Without isolation: installing project A's dependencies could break project B
pip install requests==2.0 # for project A
pip install requests==3.0 # for project B -- now A is broken!
Every project needs its own independent set of installed packages, so version requirements from unrelated projects never collide.
venv: the built-in baseline
python -m venv .venv
source .venv/bin/activate # on Windows: .venv\Scripts\activate
pip install requests
venv creates a directory with its own Python interpreter symlink and
site-packages, isolated from the system Python — no extra installation
needed since it ships with Python 3.3+. It only manages the environment
itself; you still track dependencies manually (typically in a
requirements.txt you maintain by hand or via pip freeze).
virtualenv: the third-party predecessor
Functionally similar to venv but predates it, supports older Python 2
environments, and historically offered a few extra features/faster
environment creation — largely superseded by the built-in venv for
pure Python 3 projects, but still used in some legacy toolchains.
pipenv: environment + dependency management combined
pipenv install requests
pipenv install --dev pytest
pipenv shell
Combines environment creation with a Pipfile/Pipfile.lock that pins
exact resolved versions (including transitive dependencies) for
reproducible installs across machines — addressing venv's gap of "you
manage the dependency list yourself."
poetry: dependency management + packaging + publishing
poetry init
poetry add requests
poetry add --group dev pytest
poetry install
poetry build # builds a wheel/sdist
poetry publish # publishes to PyPI
poetry centralizes dependency declaration, environment management, a
lockfile (poetry.lock) for reproducibility, and the packaging/
publishing workflow (building wheels, publishing to PyPI) in one tool
built around a single pyproject.toml — the most common modern choice
for library/application projects that need all of this together.
conda: a different scope entirely
conda create -n myenv python=3.11 numpy scipy
conda activate myenv
conda manages environments that can include non-Python dependencies
too (compiled C/Fortran libraries, CUDA toolkits, compilers) — this is
its key differentiator, and why it dominates in data science/scientific
computing where packages like NumPy/SciPy historically needed complex
native builds that pip alone couldn't easily manage across platforms.
Choosing one
| Need | Tool |
|---|---|
| Just isolate a Python environment, manage deps manually | venv + requirements.txt |
| Reproducible installs with a lockfile, simple workflow | pipenv |
| Full library/app lifecycle: deps, lockfile, packaging, publishing | poetry (or modern pip + pyproject.toml + pip-tools) |
| Non-Python dependencies (native libs, data science stack) | conda |
Interview-ready summary: venv is the built-in, minimal environment
isolator; virtualenv is its older third-party equivalent; pipenv and
poetry add dependency locking and (for poetry) packaging on top;
conda solves a broader problem — managing non-Python system
dependencies alongside Python packages — which is why it's the default
in data science despite overlapping with the others for pure-Python use
cases.