Improve compatibility with future versions of setuptools

[abravalheri]

While working on the implementation of PEP 643, I realised that if we implement a new version of metadata in setuptools, once the current version of wheel.bdist_wheel runs in deprecated scenarios, it will produce invalid metadata.

We can also expand this reasoning to other fixes and/or PEP implementations. A recent example was the fix for pypa/setuptools#1825, proposed in pypa/setuptools#4647, which caused some trouble and required the implementation of a very intrusive workaround: pypa/setuptools#4684 (comment).

I was thinking if there was any way we could address that while maintaining as much as possible a backwards compatible API (in both setuptools and wheel) so that we minimise the amount of disruption in the community while going forward¹. So I came up with the idea for this PR.

Please let me know your thoughts on the subject.

Footnotes

1. Unfortunately there are many packages in the ecosystem that are widespread but have low maintenance. It is possible that a small amount of those will never address the deprecation warning... ↩

[codecov]

Codecov Report

Attention: Patch coverage is 85.71429% with 1 line in your changes missing coverage. Please review.

Project coverage is 71.18%. Comparing base (9254a4f) to head (e2ca58b).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/wheel/bdist_wheel.py	85.71%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #638      +/-   ##
==========================================
+ Coverage   71.11%   71.18%   +0.06%     
==========================================
  Files          14       14              
  Lines        1087     1093       +6     
==========================================
+ Hits          773      778       +5     
- Misses        314      315       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[henryiii]

Would it make sense to still produce the warning though, to hopefully encourage packages to update to using setuptools directly?

[abravalheri]

Would it make sense to still produce the warning though, to hopefully encourage packages to update to using setuptools directly?

Yeah, 100%. It is better if packages are compelled to handle the deprecation explicitly.

[agronholm]

Would you mind adding a changelog note?

[henryiii]

Ahh, I thought this was only warning if it was using the internal version. I now see the warning is in the correct spot. 👍

[abravalheri]

Thank you @agronholm. I added some release notes, please feel free to modify the text to your liking.

---

A related comment:

After this change, we may be templated to just import the setuptools version elsewhere in wheel (like here) and simply delete the wheel._bdist_wheel module.

While that is a valid possibility to consider, it may involve coordinating integration tests with setuptools so that we don't introduce error in the way wheel works.

Just as an example: in pypa/setuptools#4701, as a preparation for implementing PEP 685, we are proposing to simply preserve the contents of PKG-INFO into METADATA instead of post-processing it (like wheel does).

This makes sense in the setuptools code-base because we know that the installed version of setuptools will always produce the acceptable metadata. However, the wheel CLI may be used to convert old .egg files that have old and incompatible PKG-INFO.

So there are 2 options, preserve the implementation of wheel._bdist_wheel, or coordinate with setuptools adding some forms of integration tests to avoid changes in setuptools breaking the way wheel converts old .egg files.

[agronholm]

I have a half-done local branch where I'm removing the setuptools dependency for egg conversion.

[abravalheri]

Perfect, thank you very much.