pipenv
Pipenv combines virtual-environment management, dependency declarations, locking, installation, scripts, and environment-variable loading for Python applications. Direct requirements live in a human-edited `Pipfile`; the resolver writes exact versions and hashes to `Pipfile.lock`; and commands run inside a project-specific virtual environment. It sits above pip and virtualenv rather than replacing Python packaging standards, giving application teams one workflow for install, lock, sync, run, inspect, and export.
Pipenv remains a sound choice for applications already committed to Pipfile and its workflow. For a new project in 2026, uv's speed and `pyproject.toml` alignment make it the easier default to defend.
Use it if
- Your team already uses Pipfile and Pipfile.lock and wants one maintained command for the whole application workflow
- You want direct dependencies separated from a deterministic, hash-bearing transitive lockfile
- You need first-class Linux, macOS, and Windows virtual-environment behavior from the same tool
- You value project scripts, dependency graphs, `.env` loading, and requirements export alongside locking
- You are starting a new project and want the fastest modern resolver and installer: uv offers project environments and locking with less waiting and uses the standardized `pyproject.toml` center of gravity
- You are publishing a reusable library: Pipenv's own README says it is primarily for applications, while build metadata and dependency ranges for libraries belong in `pyproject.toml`
- Your tooling expects standard project metadata: `Pipfile` and `Pipfile.lock` are Pipenv-specific, so editors, bots, build backends, and other installers may still need exported requirements or duplicate configuration
- You dislike implicit behavior tied to the working directory: Pipenv searches upward for a Pipfile, chooses or creates a virtualenv, and automatically loads `.env`, which can make the same command behave differently in neighboring directories
- You need installs to reproduce the existing lock exactly but plan to use `pipenv install` everywhere: install can update an out-of-date lock, while the documented `pipenv sync` command is the deployment-oriented operation that installs what is already locked
Setup reality
Install Pipenv outside the project environment, preferably with `pipx install pipenv`; installing it into every application environment defeats part of its job. Current PyPI metadata requires Python 3.10 or newer for Pipenv itself, although it can create environments for other interpreters that are available through the system, pyenv, or asdf. The project root is discovered by searching for `Pipfile`, and the virtualenv normally lives in Pipenv's central directory with a path-derived name. Set `PIPENV_VENV_IN_PROJECT=1` before creation if your team expects `.venv` beside the code. `pipenv install` may create a Pipfile, create an environment, resolve dependencies, and rewrite an outdated lock, so it is not the calm production command. Commit both Pipfile and Pipfile.lock, use `pipenv lock --clear` when resolver caches are suspect, and deploy with `pipenv sync --deploy` so a stale lock fails instead of changing. Automatic `.env` loading is convenient but can surprise scripts and expose conflicting variables; disable it with `PIPENV_DONT_LOAD_ENV=1` where the process manager already owns configuration. Shell activation is optional: `pipenv run` is easier to reproduce in CI than a stateful subshell. Since 2026.5.0, the old `_PIPENV_COMPLETE` completion method no longer works; completion requires the optional `argcomplete` dependency and shell-specific registration.
Patterns
Install Pipenv as an isolated CLIinstall-pipenv
pipx install pipenvKeep the environment manager outside the application environment it creates and manages.
Create an environment with a chosen Pythoncreate-project-environment
export PIPENV_VENV_IN_PROJECT=1
pipenv --python 3.13The interpreter must exist locally or be installable through configured pyenv or asdf integration.
Add a runtime dependencyinstall-runtime-dependency
pipenv install 'requests>=2.32,<3'This updates Pipfile and normally resolves a new Pipfile.lock; quote version operators so the shell does not interpret them.
Add a development dependencyinstall-dev-dependency
pipenv install --dev pytestDevelopment packages go in `[dev-packages]`; install them in a fresh environment with `pipenv sync --dev`.
Run a command without activating a shellrun-project-command
pipenv run python -m pytestThis is easier to reproduce in CI and scripts than relying on the state of `pipenv shell`.
Define and run a Pipfile scriptdefine-project-script
# Pipfile
[scripts]
test = "python -m pytest"
serve = "python -m myapp"
# terminal
pipenv run testScript values are command strings; keep complicated orchestration in a real task runner or script file.
Resolve and write the lockfilerefresh-lockfile
pipenv lock --clear`--clear` discards resolver caches and can help with stale metadata, but it also makes the run contact indexes again.
Install exactly from the committed lockdeploy-locked-dependencies
pipenv sync --deployUse sync for deployment; `--deploy` fails if Pipfile and Pipfile.lock do not agree instead of silently relocking.
Recreate runtime and development dependenciessync-development-dependencies
pipenv sync --devThis consumes the existing lock; run `pipenv lock` separately when you intentionally want new resolutions.
Inspect installed transitive dependenciesinspect-dependency-graph
pipenv graphThe graph reflects the current virtual environment, so sync first when checking whether it matches the lock.
Export locked runtime requirementsexport-requirements
pipenv requirements > requirements.txt
pipenv requirements --dev > requirements-dev.txtExported files are derived artifacts; choose one source of truth and regenerate them when Pipfile.lock changes.
Find the project, environment, and interpreterlocate-project-tools
pipenv --where
pipenv --venv
pipenv --pyThese commands are the quickest way to diagnose an unexpected parent Pipfile or centrally stored virtualenv.
Alternatives
| Package | Registry | Pick it when |
|---|---|---|
| uv | PyPI | You want a very fast installer, resolver, project manager, and lockfile around `pyproject.toml` |
| poetry | PyPI | You want dependency management and package build or publish workflows centered on `pyproject.toml` |
| hatch | PyPI | You maintain Python packages and want environments, builds, versioning, and scripts under standard project metadata |