Implement PEP 643 (Dynamic field for core metadata)

[abravalheri]

IMPORTANT: #4701 needs to be merged first, then this PR needs to be rebased (probably there will be conflicts). It might also be a good idea to wait until the next version of wheel is released (v0.45).

Summary of changes

This PR attempts to implement the 2nd approach suggested in #2685:

Mark everything as Dynamic if it comes from setup.py, but not if it comes from setup.cfg or pyproject.toml.

Values given via setup.py are considered dynamic for the sake of simplicity.

The "trick" implemented in this PR to avoid the problems with plugins/customisations described in #4629 (comment), is to mark static values instead of dynamic ones.

This marking is a bit "unconventional" (via subclasses of buit-in types), but it simplifies the tracking of changes and is backward compatible with the existing distutils/setuptools code base.

OPEN PROBLEM: wheel.metadata.pkginfo_to_metadata hardcodes Metadata-Version: 2.1.

• Possible solution: assume that the generated PKG_INFO file in setuptools is good enough and obviate usage of pkginfo_to_metadata => Preserve original PKG-INFO contents when creating wheel (instead of calling wheel.metadata.pkginfo_to_metadata) #4701.

Closes #2685

Pull Request Checklist

• Changes have tests
• News fragment added in newsfragments/.
  (See documentation for details)

[abravalheri]

@jaraco would this kind of approach be acceptable in setuptools?

[jaraco]

I haven't gone deep into the details, but at a high level, this change seems to honor the intentions of PEP 643.

It's not obvious to me what changes from a user's perspective. What projects are affected by this change? Does it simplify or complicate their experience? I think the answer is that projects largely don't have to do anything, but this change gives more fidelity to the metadata (at the cost of the added logic maintenance). If that's right, that seems like a fair tradeoff. Happy to give it a try. Let me know if there's a type of project you think I should run it against.

[abravalheri]

Thank you very much @jaraco.

The motivation of the PEP is purely to catch up with the standards, I don't think it changes much from a user's perspective. However it may be used by frontends/installer for optimisations and therefore improve installation speed.

Let me know if there's a type of project you think I should run it against.

This week I will not have the time, but my plan is to build some projects and try to upload them to test.pypi.io, to see if the metadata still passes all the validations done by PyPI. I that goes well, we can release the change and start working on PEP 639.

[Avasam]

An object parameter should match anything. You should be able to avoid using Any here.

Suggested change

	def is_static(value: Any) -> bool:
	def is_static(value: object) -> bool:

You can also make this function a type-guard with:

Suggested change

	def is_static(value: Any) -> bool:
	if TYPE_CHECKING:
	from typing_extensions import TypeGuard # Added to typing in Python 3.10
	def is_static(value: object) -> TypeGuard[Static]:

[abravalheri]

Thank you!

In 72c4222, I went with the first approach suggested because I don't want the type checker to change the type it sees in a variable. For example if a variable is _static.Str | str, I would like the typechecker to keep considering it _static.Str | str...

Later if we need, we can change it to a TypeGuard.

[ofek]

Has there been any update on this? At work we have a dependency in our chain that causes a source distribution build during resolution which takes dozens of minutes which would be unnecessary with this implemented.

[abravalheri]

I did some very simple tests with test.pypi.org in a couple of projects:

• https://test.pypi.org/project/test-setuptools/75.7.0.post20250108 (setuptools itself)
• https://test.pypi.org/project/ini2toml/0.16a0
• https://test.pypi.org/project/validate-pyproject/0.23b1

The test was done using:

[build-system]
requires = ["setuptools @ git+https://github.com/abravalheri/setuptools@issue-2685-pep643", ...]

I think it makes sense to move ahead with this one now and allow a couple of weeks to see if any edge cases comes up. Worst case scenario can revert back.