Should sdists include docs and tests?

My position hasn’t changed from what I said above. People have different opinions and intentions for their sdists, and right now that’s valid. Some people view them as “a way to build a wheel on platforms where wheels aren’t available”. Some people view them as “a way to ship all of the artifacts I consider part of what’s needed to work on my project”. Some people view them as “a way to ship everything I expect a redistributor to need”.

Getting a policy on a single, unified view of what a sdist is, will be a potentially controversial debate. Publishing and promoting the resulting definition, so that everyone publishing sdists knows what’s expected of them, will be an exercise in itself. Writing tools that validate if a sdist conforms to that definition (check that tests and docs are included, for example) is another aspect, as is changing the culture to make use of such tools commonplace.

But IMO, this discussion has run its course. We’ve established that people have different opinions, even though for some people, a common approach is important. We need to look at the next step, which is probably for someone who cares sufficiently, to draft a document that is intended to become a PEP (or some other form of document with the force of a standard) and manage the process of gaining consensus.

5 Likes