Packaging a Python project with pyproject.toml

Goal

Make the project installable and buildable with standard tools from a single declarative file, so that contributors and pipelines do not depend on a particular workflow tool.

Prerequisites

A package layout (src/yourpackage/ recommended) and a chosen build backend (setuptools, hatchling, flit-core or similar).

Steps

1. Add a [build-system] table naming the backend and its version requirement.
2. Add a [project] table with name, version (or dynamic = ["version"]), description, readme, requires-python, license, dependencies and optional-dependencies for extras such as test or docs.
3. Declare entry points ([project.scripts]) instead of shipping ad hoc launcher scripts.
4. Put tool configuration ([tool.ruff], [tool.mypy], [tool.pytest.ini_options]) into the same file to keep the repository root tidy.
5. Build with python -m build and install into a fresh virtual environment to verify that the built distribution contains everything the code imports.
6. Pin the full dependency tree for applications in a lockfile; keep library dependencies as ranges.

Expected result

pip install . and pip install -e . work; the built wheel installs cleanly elsewhere; metadata appears correctly on the package index.

Limits and test basis

Application lockfiles are not standardised across tools; choose one and document it. Data files need explicit inclusion rules per backend. The structure follows the cited guide and PEP 621.