Pipfile: Python Dependency Declaration Format
A Pipfile is a TOML-formatted file that declares a project’s Python dependencies for use with Pipenv. It was originally proposed as a successor to requirements.txt, adding structured runtime and development dependency sections alongside a paired Pipfile.lock for reproducible installs.
The standalone pipfile specification project at pypa/pipfile has not seen substantive activity since 2019. The format lives on inside Pipenv, which reads and writes both the Pipfile and Pipfile.lock. The broader Python packaging ecosystem moved toward dependency declarations in pyproject.toml under PEP 621, and the two formats are no longer in active competition.
File Structure
A Pipfile uses TOML syntax with named sections for sources, runtime packages, development packages, Python requirements, and project scripts:
[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"
[packages]
requests = ">=2.28"
flask = "*"
[dev-packages]
pytest = ">=7.0"
ruff = "*"
[requires]
python_version = "3.12"
[scripts]
test = "pytest tests/"
start = "flask run"The * value declares a package with no version constraint. Runtime dependencies live under [packages], with development-only tooling under [dev-packages]. The [requires] section pins the Python version, and [scripts] defines named commands that Pipenv can invoke with pipenv run <name>.
Pipfile.lock
Running pipenv lock resolves the loose constraints in a Pipfile against the configured indexes and writes a fully pinned Pipfile.lock that records every transitive dependency at an exact version, with content hashes for verification. The lockfile is the artifact responsible for reproducible installs across machines, while the Pipfile holds the human-authored constraints. See What is a lockfile? for background on the pattern.
Limitations
- Tied to Pipenv. No other widely used installer reads or writes the format directly, in contrast to
requirements.txt(read by pip, uv, and most installers) andpyproject.toml(read by every standards-compliant build frontend and most modern package managers). - Outside the standard track. The format predates PEP 621 and was never standardized through the PEP process, so it carries none of the cross-tool guarantees that
pyproject.tomlprovides. - No project metadata. A Pipfile declares dependencies but cannot describe a distributable package (name, version, entry points, build configuration). Projects that need to publish to PyPI keep a separate
pyproject.tomlorsetup.pyalongside it. - Stalled specification. The
pypa/pipfilerepository has been quiet for years, and changes to the format effectively ship as Pipenv changes rather than through a published spec.
Migrating Off Pipfile
Projects moving from Pipenv to a pyproject.toml-based workflow can map [packages] to [project] dependencies, [dev-packages] to [dependency-groups], and [requires] python_version to requires-python. The How to migrate from Pipenv to uv guide walks through the translation in full and covers the automated migrate-to-uv tool that reads a Pipfile and Pipfile.lock directly.
Pipfile should not be confused with pipenv, the tool that reads and writes the format, or with pip, the standard installer that has no involvement with the Pipfile format despite the similar name.