The wheel project is documented here as being the reference implementation for wheels, but not as offering a programmatic API:
This library is the reference implementation of the Python wheel packaging standard, as defined in PEP 427.
It has two different roles:
- A setuptools extension for building wheels that provides the
- A command line tool for working with wheel files
As a general principle, I tend to believe that we should have library implementations of all of the packaging standards that we have defined, so that user code can be built on top of them without re-implementing the details of the specs. In this case, the obvious consumers of such a library would be build backends¹, but I have also found a need to create wheels in adhoc code and test harnesses.
The wheel project has historically preferred not to support an API (@agronholm @dholth is that a fair statement?) so it’s not clear to me where users should get that library. I don’t want to risk community upset by unilaterally creating a competing wheel project, in particular as the “obvious” way to kick-start such a library would be to copy code from the wheel project, but I’d like to open a discussion on
- Whether I’m right that we should have a reference library implementation of the wheel spec.
- How we should do that in a way that’s minimally disruptive to the packaging community.
What are people’s thoughts? In particular, what are the wheel project maintainers’ feelings on the matter? (I originally considered raising this as a ticket on the wheel project tracker, but it was difficult to frame the question in a way where the “obvious” answer wasn’t simply “the project doesn’t offer a programmatic API”).
For background, this question was prompted as a result of thinking about how I can test my project for generating editable wheels in preparation for a PyPI release - the code produces the files that need to be bundled into a wheel by the backend, but I do not want to include wheel-building code in the
editables library itself.
¹ Other than setuptools, who are well-supported by the
bdist_wheel extension included in