Forcing un-pure wheel, computing the wheel name in advance

[nextsilicon-itay-bookstein]

The well-trod path for building python extension modules is by letting their build be driven by the setuptools machinery. I tried to drive the build of some extensions from another build-system (e.g. cmake), and then injected those extensions into the wheel using MANIFEST.in.

This is inspired by scikit-build-s use of package_data to achieve the same: https://github.com/scikit-build/scikit-build/blob/676e110315a971abb856edbd6df0c74293e5ba2d/skbuild/setuptools_wrap.py#L882C20-L882C20

However, I ran into an issue with the way wheel classifies the package as un-pure: it does so only if it has extension modules or C libraries (https://github.com/pypa/wheel/blob/5bff47e33e589b9d69f84dee2542ac589862ce4a/src/wheel/bdist_wheel.py#L263-L265). This gets me a wrongly-classified wheel. I looked around and there seems to be no escape-hatch for customizing this. scikit-build-s workaround is to override the distclass: https://github.com/scikit-build/scikit-build/blob/676e110315a971abb856edbd6df0c74293e5ba2d/skbuild/setuptools_wrap.py#L770-L775

This is, however, less declarative than I'd like (with respect to the move towards pyproject.toml etc). I was wondering what approach would make sense here.

Also, because the wheel name is computed dynamically, and is part of the interface, I resorted to a solution derived from this: https://stackoverflow.com/questions/51939257/how-do-you-get-the-filename-of-a-python-wheel-when-running-setup-py/60773383#60773383 Which is quite unfortunate. When I express the dependencies in the build system (input files and output files) it's very helpful to know the output filename in advance.

Thanks for the advice!

[nextsilicon-itay-bookstein]

Also, for reference, a very similar need was expressed in this stackoverflow thread: https://stackoverflow.com/questions/45150304/how-to-force-a-python-wheel-to-be-platform-specific-when-building-it