One File to Describe Your Project (pyproject.toml)

Why this matters

pyproject.toml (PEP 518/621) is the standard project manifest in 2026 — it replaces setup.py, setup.cfg, Pipfile, and the bespoke configs of 90% of tools. It carries project metadata, dependencies, build backend, and tool config (ruff, mypy, pytest all read from it). A fresh project in 2026 has one pyproject.toml and that's it — no setup.py, no setup.cfg. Knowing every section by heart is the difference between 'I copy from a template' and 'I can ship a Python library to PyPI'.

Demo

pyproject.toml is the single source of truth for a Python project: it declares direct dependencies, the required Python version, build backend, optional dependency groups (like dev), and the configuration of every tool (ruff, mypy, pytest) that reads from it. Before PEP 518/621 you needed setup.py, setup.cfg, MANIFEST.in, tox.ini, and a bespoke requirements-dev.txt — all of which are now replaced by one file. A production-grade pyproject.toml also declares [project.scripts] entry points so that pip install automatically wires up CLI binaries on the user's PATH.

Try it yourself

1. Create a pyproject.toml with the layout above. Run uv pip install -e . (editable install) and confirm pip list shows your package.
2. Add a [project.scripts] entry pointing at a function in your code. Re-install. Now there's a CLI binary on your PATH.
3. Add a [tool.ruff] section. Run ruff check . — it picks up the config automatically. This is the new standard.
4. Try uv pip install -e ".[dev]" to install with optional deps. This is how dev-only deps stay out of production.

References

• PEP 621 — Project metadata
• PEP 518 — Build system requirements
• Hatchling docs