pyproject.toml missing `dynamic = ["version"]` breaks installation with uv

[jiridanek]

Problem

Installing lintrunner with uv fails with the following error:

× Failed to download and build `lintrunner==0.12.11`
├─▶ Failed to parse:
│   `/root/.cache/uv/sdists-v9/pypi/lintrunner/0.12.11/.../pyproject.toml`
╰─▶ TOML parse error at line 5, column 1
      |
    5 | [project]
      | ^^^^^^^^^
    `pyproject.toml` is using the `[project]` table, but the required
    `project.version` field is neither set nor present in the
    `project.dynamic` list

Root Cause

The current pyproject.toml has a [project] table but doesn't declare the version field:

[project]
name = "lintrunner"
requires-python = ">=3.6"
classifiers = [...]

Per PEP 621, when using the [project] table, the version field is required unless it's listed in dynamic. Since maturin gets the version from Cargo.toml, this works at build time, but uv validates the pyproject.toml strictly before invoking the build backend.

Suggested Fix

Add dynamic = ["version"] to the [project] table to indicate that the version is provided dynamically by the build backend:

[project]
name = "lintrunner"
requires-python = ">=3.6"
dynamic = ["version"]  # <-- add this line
classifiers = [...]

This is the standard way to declare that maturin will provide the version from Cargo.toml.

Context

This issue affects users trying to build PyTorch from source using uv, as PyTorch's requirements.txt includes lintrunner. The workaround is to filter out lintrunner or use pip instead of uv.

Environment

• uv version: 0.9.x+
• Python: 3.12
• Platform: Linux (ppc64le, but affects all platforms)

[jiridanek]

Additional context on timing:

This is a relatively recent issue caused by stricter validation introduced in uv 0.5.10 (December 2024).

• uv 0.5.9 and earlier: Did not strictly validate project.version - let the build backend handle it
• uv 0.5.10+: Enforces PEP 621 requirement that project.version must be set or listed in project.dynamic

The lintrunner pyproject.toml has technically been non-compliant with PEP 621 since using the [project] table, but it only became a practical problem when uv started enforcing this. There's a related uv issue documenting this regression: astral-sh/uv#10039.

The fix (dynamic = ["version"]) is straightforward and doesn't change any behavior - it just declares that maturin provides the version from Cargo.toml, which is already what happens.