What does the `[project]` table in `pyproject.toml` (PEP 621) standardize?

## The problem PEP 621 solved For most of Python's history, project metadata was code. A setuptools project declared its name, version and dependencies by calling a function inside an imperative script, which meant that reading a project's metadata required *executing arbitrary Python* — and that the metadata could differ depending on the machine, the environment or the phase of the moon. Later a declarative config file moved most of it out of code, but it was still setuptools' own format. Meanwhile every other tool that wanted to know your dependencies invented its own file. Two PEPs fixed this in sequence. PEP 518 introduced `pyproject.toml` with a `[build-system]` table, so a project could name the build backend it needs and stop assuming setuptools. PEP 621 then standardized the metadata itself, in a `[project]` table in that same file. ## What is in the table The standard fields cover everything the packaging ecosystem needs to describe a distribution: - **Identity** — `name` (normalized by the packaging rules, so case and separators do not matter) and `version`. - **Description** — `description` (one line), `readme` (a file reference or inline text), `keywords`, `classifiers`, `urls`. - **People and terms** — `authors`, `maintainers`, `license` and license files. - **Compatibility** — `requires-python`, a version specifier such as `">=3.11"`. Installers use it to refuse or to pick an older release rather than install something that cannot run. - **Dependencies** — `dependencies`, a list of requirement strings, plus an optional-dependencies table whose keys are **extras**: named optional feature sets a consumer opts into by requesting the distribution with that extra. - **Entry points** — console scripts, GUI scripts and plugin groups, which become the executable shims an installer drops into the environment's `bin` directory. There is also `dynamic`, a list naming fields the build backend will compute at build time rather than read statically — the escape hatch for a project whose version comes from source control or from a module attribute. Anything not in `dynamic` must be static, and that is the point: a tool can read `pyproject.toml` and learn the metadata without running any of the project's code. With `tomllib` in the standard library since Python 3.11, reading that table is a three-line script — which is precisely why so many tools can agree on it. ## The abstract-versus-concrete distinction The single most common interview trip-up here is putting exact pins in `dependencies`. That list is **abstract**: it describes what your project can work with, as ranges and markers, because whoever installs your distribution must be able to satisfy your requirements *and* everyone else's simultaneously. A library that pins an exact version of a shared dependency makes itself un-co-installable. The exact resolved set — this version of that transitive dependency, with this hash — belongs in a lock file, which an application commits and a library generally does not publish. The declaration says what is acceptable; the lock says what was chosen. All-in-one managers keep both, and edit both when you add a dependency. ## From source metadata to installed metadata The `[project]` table is *source* metadata. When a backend builds a wheel, it translates those fields into the standardized core metadata file inside the distribution, and after installation that file is what `importlib.metadata` reads at runtime. So the table you write and the metadata a running process can introspect are the same information in two encodings — which is why the name you install and the name you import are separate concepts, and why a distribution can legitimately install several importable packages, or none with a matching name. ## What it does not standardize PEP 621 covers metadata, not behaviour. It says nothing about how a build backend compiles extension modules, how a project manager resolves, what a lock file looks like, or how tests are run. Each tool keeps its own configuration under a `[tool]` table namespaced by the tool's name, and other tools ignore it. That split is deliberate and is exactly what makes the declaration portable while the workflow is not: your `[project]` table survives a change of project manager unchanged, and everything under `[tool]` does not. One more consequence worth naming: because `[project]` is standard, a repository can be read by tooling that has never heard of the manager you chose — a security scanner, a dependency bot, an internal audit script. The declaration is the interoperability layer, and it is the reason a bet on any one all-in-one manager is smaller than it looks.