Upcoming changes in the pypa/wheel project

Packaging
41

More worryingly, it seems that the official python Docker images also updated wheel, but not setuptools. I’ll have a few stern words for the maintainers of said images.

42

A test workflow was suggested where the top 100 packages would be installed while providing the local version of wheel. This wouldn’t cover all the corner cases, but might be helpful. Is there another PyPA project already doing this?

43

setuptools is testing against seven popular ones here:

https://github.com/pypa/setuptools/blob/3a3144f0d2887fa37c06550f42a101e9eebd953a/setuptools/tests/integration/test_pip_install_sdist.py#L50-L60

And against 17 in tests using this file:

https://github.com/pypa/setuptools/blob/3a3144f0d2887fa37c06550f42a101e9eebd953a/setuptools/tests/config/setupcfg_examples.txt

1 Like
44

I’d like to post a small “post-mortem” on the two wheel releases that I had to yank. It’s obvious by now that nobody foresaw all of the issues that would surface:

  • wheel.macosx_libfile still being imported even by the latest setuptools if wheel is importable
  • projects constraining setuptools to a problematic version in their build-system.requires that still downloads the latest wheel
  • the official Python Docker images installing an incompatible combination of setuptools and wheel without checking (this has been fixed now by constraining wheel in said images, as they’re unwilling to upgrade setuptools, having also caused breakages in the past by doing so)

I’ve been trying to figure out how to move forward. Given that older versions of setuptools which install wheel without any version constraints will still be around for a very long time, wheel will unfortunately have to maintain compatibility with those old setuptools versions for the foreseeable future.

So, what are the next steps then? Here are a few ideas that came to my mind:

  • in wheel, restore the bdist_wheel entry point and module, importing the setuptools.command.bdist_wheel module when available, otherwise falling back to its own implementation
  • in wheel.bdist_wheel, switch from DeprecationWarning to FutureWarning when the bdist_wheel shim is used, for broader user awareness
  • the WheelFile API should be added to packaging (#805; this is on me to finish)
  • once the above is done, setuptools should switch to that API, entirely stop vendoring wheel and adopt any necessary modules from it (such as macosx_libfile)

My immediate goal is to make a new wheel release which restores the bdist_wheel command, and to somehow try to test that it doesn’t ruin everyone’s day when released. Given that the entire focus on the last couple releases has been decoupling wheel from setuptools, the only significant change in the forthcoming release would be that wheel drops its vendored packaging in favor of a run-time dependency.

6 Likes