Requires-Python information not uploaded to PyPI?

[pganssle]

Problem

Although Sphinx has added requires_python into its setup() function, I believe the current versions up there now were uploaded using an old version of twine or built with an old version of setuptools, because the Requires-Python metadata does not seem to be present.

I am erroneously installing Sphinx on Python 3.3 for this project, and it is causing a failure because it is downloading an unsupported version.

If you compare python-dateutil to sphinx on PyPI, you'll see that Sphinx is missing the "Requires: Python >=2.7, !=3.0., !=3.1., !=3.2., !=3.3." text below the list of maintainers.

Solution

I think the solution here is to issue new releases for all affected versions (possibly post releases), going back to the last one that supports Python 3.3, using an upgraded version of twine and setuptools. Simply issuing a single new release with this problem fixed will not solve the problem, because pip will choose the most recent version that doesn't explicitly exclude Python 3.3 in the metadata and download that - which means all the existing releases won't be excluded.

Word of Warning:
You cannot re-publish a module you un-publish, so I recommend uploading post releases for the affected versions and test that with pip >= 8.0 on Python 3.3. If pip still ends up picking up the non-post releases, you may have to un-publish the non-post versions, assuming that still matches exact strings like Sphinx==1.7.3.

[tk0miya]

Thank you for advice. Actually, we added requires_python since 1.7.3. And we dropped py33 support since 1.5.
As you said, it is better to add requires_python to past packages.
But AFAIK, python3.3 already becomes EOL at last autumn. So I feel no updates are needed.
https://www.python.org/dev/peps/pep-0398/#x-end-of-life

[pganssle]

@tk0miya I think it's actually still important to go back and make post releases for anything that actually contains python_requires. One of the reasons for this is that the way you have it now, your release process is broken and is not uploading the python_requires metadata. This needs to be fixed before it becomes a problem.

Another reason is that right now what's happening is that I believe that python_requires is used in two places - the first is that PyPI uses it when you make a pip request to determine which package to give you. You're evidently not interested in fixing this part for Python 3.3, which is fine. However, pip also uses it at install time to throw an error when you try to install a library outside of the python_requires requirements. So now what happens is that anything that even installs sphinx will download the wrong version and then break when the version requirements are enforced. If all versions of the library with python_requires included also upload the metadata correctly, I believe you will no longer have this problem.

[shimizukawa]

In fact, we have python_requires in setup.py by 78c1fde (sphinx-1.7.2 or later), however python setup.py sdist upload command didn't reflect Requires-Python metadata to PyPI. I found that we must use twine upload instead to reflect such metadata.
The next Sphinx version will be uploaded using twine (ab10174).

Currently, we have no plan to re-upload past versions. So please set the environment marker on the user side and control it.

[pganssle]

Seems like it would be incredibly easy to upload a post version of your library with the metadata, and would serve as good practice for how to do so in future.

Presumably you will waste more time dealing with subsequent reports about this kind of thing than the marginal cost of cutting a post release with the right metadata.

If you prefer to leave your packages in a broken state that's fine I suppose.

[tk0miya]

Requires-Python metadata has been applied since Sphinx-1.7.5.
And we determined not to re-upload past releases.
So I'm closing this now.
Thank you for advice!