You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
build.util.project_wheel_metadata was deprecated in 1.5.1, but the deprecation points only at the python -m build --metadata CLI. The programmatic replacement described in #1084 — build.util.wheel_metadata() with a check_dependencies flag — does not exist in 1.5.1 or on main. The merged diff for #1084 (cd56622) added the deprecation warning but not the new function.
Net effect: consumers of a supported, in-process Python API are being told to migrate to a subprocess, with no supported programmatic path offered.
Why this matters
project_wheel_metadata returns a live importlib.metadata.PackageMetadata object. python -m build --metadata instead emits a JSON core-metadata mapping (snake_case keys, project_urls as a mapping) over stdout. For a library that reads metadata programmatically, the recommended migration therefore means: spawn a child interpreter, capture stdout, parse JSON, and rewrite every consumer that relied on the Message interface — losing the object and the runner customization point.
To make the trade-off concrete, I put up two alternative PRs downstream:
Keep a supported in-process entry point (un-deprecate, or expose the _project_wheel_metadata core), and only then point the deprecation at it.
Until a supported programmatic replacement lands, the deprecation message recommending a CLI leaves library consumers without a like-for-like path. Refs #557, #619, #1084.
Summary
build.util.project_wheel_metadatawas deprecated in 1.5.1, but the deprecation points only at thepython -m build --metadataCLI. The programmatic replacement described in #1084 —build.util.wheel_metadata()with acheck_dependenciesflag — does not exist in 1.5.1 or onmain. The merged diff for #1084 (cd56622) added the deprecation warning but not the new function.Net effect: consumers of a supported, in-process Python API are being told to migrate to a subprocess, with no supported programmatic path offered.
Why this matters
project_wheel_metadatareturns a liveimportlib.metadata.PackageMetadataobject.python -m build --metadatainstead emits a JSON core-metadata mapping (snake_case keys,project_urlsas a mapping) over stdout. For a library that reads metadata programmatically, the recommended migration therefore means: spawn a child interpreter, capture stdout, parse JSON, and rewrite every consumer that relied on theMessageinterface — losing the object and therunnercustomization point.To make the trade-off concrete, I put up two alternative PRs downstream:
ProjectBuilder/DefaultIsolatedEnv/metadata_path()(i.e. whatbuild.util._project_wheel_metadatastill does internally). Clean; no consumer changes.python -m build --metadata(recommended path) jaraco/jaraco.packaging#27 — follows the CLI recommendation literally. Breaking return-type change and a rewrite of every consumer, shown side-by-side.The fact that the tidy fix (#26) just re-inlines
build's own non-deprecated internals suggests the capability should stay public.Request
One of:
wheel_metadata()described in ⚠️ feat(util): deprecate project_wheel_metadata #1084 (the deprecation message already implies it exists), or_project_wheel_metadatacore), and only then point the deprecation at it.Until a supported programmatic replacement lands, the deprecation message recommending a CLI leaves library consumers without a like-for-like path. Refs #557, #619, #1084.