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 (

wheel/src/wheel/bdist_wheel.py

Lines 263 to 265 in 5bff47e

	self.root_is_pure = not (
	self.distribution.has_ext_modules() or self.distribution.has_c_libraries()
	)

).
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