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]: