data_files specified to filelist during default collection
Thanks for the contrib.
I'm a little reluctant to add this for a few reasons.
That said, let's work toward a better solution.
I'd feel a lot better if distutils were to extract this functionality into a (perhaps private) method, and then Setuptools could call this private method (if it exists) or call a copy of it in the codebase for forward compatibility. As this requires committing to the Python codebase, perhaps that's too high a bar.
At the very least, I'd like for the code to clearly indicate why the setuptools sdist overrides the distutils sdist, and what it's intended to do... and to have a test to capture this new expectation.
What do you think?
Disclaimer: I'm not entirely synced on setuptools' end goals.
Context: I've been trying to build a
Longer description of the "issue" that I've had (as well as @bb-migration at least): When
Responses to your @jaraco's bullets:
 As a base yes, but updated to use
 I'm not entirely sure what you mean by this. I guess this is a sibling of your bullet .
 True, I need to add some.
 I suppose this is all moot then if the use of
 Possibly, I don't know what every pull request is...
 I think this patch is technically the opposite, really. By programatically filling the
As for why
I'm going to give the setuptools docs on ReadTheDocs a good read through again.
In this series of commits, I implement what I describe - I've refactored the functionality in distutils to provide hooks into aspects of the functionality, allowing the setuptools subclass to override behavior surgically. Now the codebase is in a healthy place, and when support for Python 3.6 is dropped, that compat module can be removed as well. More importantly, if the project chooses to restore the data files discovery, it should be a simple matter of removing the suppression of the
Would you consider submitting a new PR with a test demonstrating the expectation?