The recently added overview (which is overall pretty great), implies that for Pure Python packages, you only want to upload a sdist. While it's generally true that some of the wins are most obvious with packages that contain compiled code, pure python projects should pretty much always upload wheels as well (and for them, it's generally easier, and often times a single wheel file is all they need).
As we progress packaging forward, one thing that is for certain is that we know that we will someday be able to have PyPI present information like Requires-Dist for wheel files, allowing pip and such to resolve dependencies without downloading the files and executing a Python subprocess. We don't know that we are going to be able to do that for sdists (though of course we hope to). Projects that don't upload wheels risk, in this likely future, from forcing installers to rely on much slower mechanisms for dependency resolution.
Of course Wheels are also just generally faster to install, even for pure python projects the speed up can be 1-2s per package, which can add up greatly over even a fairly modest dependency set (30 depencies means 30-60s more time if they don't provide wheels).
This kind of throws this section of the overview off a bit, since the entire premise of this section is the gradient from single .py files, to pure python packages, to packages with compiled artifacts. That gradient is probably worth while to express, but it should have some distinction other than sdist vs wheels, because you should produce both packages, for both layers of the gradient (omitting plain .py files for obvious reasons).
Perhaps a better way to describe this gradient would be indicating the tools you use to build it? You can use something simpler like flit for pure python, whereas if you're doing something compiled you're likely going to need setuptools or numpy.distutils or something.
The recently added overview (which is overall pretty great), implies that for Pure Python packages, you only want to upload a sdist. While it's generally true that some of the wins are most obvious with packages that contain compiled code, pure python projects should pretty much always upload wheels as well (and for them, it's generally easier, and often times a single wheel file is all they need).
As we progress packaging forward, one thing that is for certain is that we know that we will someday be able to have PyPI present information like
Requires-Distfor wheel files, allowing pip and such to resolve dependencies without downloading the files and executing a Python subprocess. We don't know that we are going to be able to do that for sdists (though of course we hope to). Projects that don't upload wheels risk, in this likely future, from forcing installers to rely on much slower mechanisms for dependency resolution.Of course Wheels are also just generally faster to install, even for pure python projects the speed up can be 1-2s per package, which can add up greatly over even a fairly modest dependency set (30 depencies means 30-60s more time if they don't provide wheels).
This kind of throws this section of the overview off a bit, since the entire premise of this section is the gradient from single
.pyfiles, to pure python packages, to packages with compiled artifacts. That gradient is probably worth while to express, but it should have some distinction other than sdist vs wheels, because you should produce both packages, for both layers of the gradient (omitting plain.pyfiles for obvious reasons).Perhaps a better way to describe this gradient would be indicating the tools you use to build it? You can use something simpler like
flitfor pure python, whereas if you're doing something compiled you're likely going to needsetuptoolsornumpy.distutilsor something.