Support wheel.exclude

[dalcinl]

Right now, wheels use sdist.{include|exclude} to decide on file inclusion. The problem with this approach is that sdist must include non Python sources (C/C++/Fortran/Cython/SWIG), but these files should typically not go into the wheel. Therefore, the need of wheel.exclude is rather obvious. I'm not so sure about the wheel.include, I can only think for files generated during the build that are not explicitly installed in CMakeLists.txt. I guess supporting wheel.include would not harm that much, even if the use case is not totally clear just yet.

If there is support for this proposal, I can contribute the implementation in an upcoming PR. I'm not sure right now what's the proper way of using settings.sdist.{include|exclude} as a fallback if settings.wheel.{include|exclude} is not specified, I guess we somehow need such an approach for backward compatibility reasons.

[henryiii]

Wheels do not use those. Wheels are built, they are not copied. There are only two types of files in the wheel: any files installed by CMake are put in the wheel. And if you use the automatic Python package discovery (or manually set it), then all files in the package are copied. If you place files inside the package you don't want copied, then that could be a use case for wheel.exclude. Though it's probably better to not place files you don't want in the auto-copied package if possible. :)

[dalcinl]

And if you use the automatic Python package discovery (or manually set it)

Oh, I see. If I set wheel.packages = [] in config, then whatever I do in CMake (not less, but no more) will trump.

If you place files inside the package you don't want copied, then that could be a use case for wheel.exclude

Despite I can do everything in CMake, including the copy or Python *.py[i] files, package discovery is still quite convenient to use. I would argue most folks distributing packages that use Cython (or plain C) sources have an use case for automatic package discovery supplemented with wheel.exclude.

[henryiii]

FYI, the fact that package discovery doesn't allow you to modify the packages is actually quite useful in setting up editable installs. Filtering out files with wheel.exclude might not affect editable installs. It's required for Cython support, for example: #516.

[dalcinl]

When referring to Cython, I was talking about .pyx files, not *.pxd files. *.pyx files should go into the sdist but not into the wheel, while *.pxd files would most likely go into both the sdist and wheel, although whether *.pxd should go into the wheel should ultimately be the decision of the authors/maintainers. Similar comments would apply to *.c versus *.h files (as Python extension modules may expose a C API, being NumPy a prime example).

I didn't quite get the connection between #516 and this issue. If you are not convinced about the convenience of wheel.exclude and fine-grained control on file inclusion/exclusion, and you would rather put the burden on authors to install stuff via CMake, that's totally fine with me. Please feel free to close this issue and move on.

[henryiii]

No, I'm still not against wheel.exclude. I'm just saying those things might be reachable in editable mode, at least in some situations, and therefore might need a note. But just having it for wheels is still useful.