dynamic-metadata

dynamic-metadata defines a plugin protocol that lets a Python build backend compute [project] fields (version, readme, dependencies, …) at build time. Plugins are configured as an ordered array of tables, [[tool.dynamic-metadata]], each naming a provider. Entries run in order, so a later entry sees every field an earlier entry produced.

A minimal example reads the version out of a file with the bundled regex plugin:

[build-system]
requires = ["...", "dynamic-metadata"]
build-backend = "..."

[project]
dynamic = ["description", "version"]

[[tool.dynamic-metadata]]
provider = "dynamic_metadata.regex"
field = "version"
input = "src/my_package/__init__.py"

Because entries run in order, a later one can reference an earlier result. Here the template plugin builds a description from the name and the version produced above:

[[tool.dynamic-metadata]]
provider = "dynamic_metadata.template"
field = "description"
result = "This is {project[name]}, version {project[version]}"

Your build backend must support dynamic-metadata for this to work. Build backends known to support this currently include:

• scikit-build-core (1.0+)

If you have a build backend, it's easy to add support, you don't even need to depend on this project to do it.

The documentation is split by audience:

• For users — configure plugins in pyproject.toml.
• Bundled plugins — the plugins shipped with this package (ast, regex, template, from_file, static, readme_fragment, substitute, pin_installed).
• For plugin authors — implement the hooks; no runtime dependency on this package required.
• For backend authors — drive plugins from a build backend by calling the reference loader.
• Reimplementing the loader — drive plugins without a dependency on this package.