setuptools could respect python_requires

[jdufresne]

Example: setup.py

from setuptools import setup

setup(
    name="my package",
    py_modules=["mypackage"],
    python_requires=">=3.4",
)

Example steps to reproduce:

$ python2 setup.py install 
... 
Installed .../lib/python2.7/site-packages/my_package-0.0.0-py2.7.egg
Processing dependencies for my-package==0.0.0
Finished processing dependencies for my-package==0.0.0

Expected: Command fails with an error explaining that the Python version isn't supported.

---

Some packages workaround this by adding the following to the top of their setup.py:

if sys.version_info < (3, 4):
    raise Exception(...)

Rather than relying on each package to implement this, it could be handled once by setuptools.

An important use case, after porting a package to Python-3-only, one may mistakenly do:

$ python setup.py bdist_wheel 

On a system where python is Python 2 (most Linux systems), this produces a Python 2 wheel instead of a Python 3 wheel. This is clearly a mistake by the user, but if setuptools were to bail early, the mistake wouldn't make it to PyPI.

[jaraco]

Similarly, a “universal” declaration should fail if any extension modules are present. Interestingly, the need for this feature goes away entirely when Python 2 support is dropped.

[pganssle]

This has some problems, which are essentially the same problems that invoking setup.py directly has, namely that in order to respect python_requires, setup() needs to run successfully, at least to the point where it parses the python version requirement. This means that anyone counting on setup.py only being run in Python 3 may have arbitrary failures.

Another issue is that python_requires is really intended to apply to the installed version of the package. It's entirely plausible to build a Python 3-only package with Python 2 and vice versa, it's just kinda rarely done. It's not a big deal, but given the other problems with this approach, I'm not sure it makes sense to conflate the two pieces of metadata.

It would make sense if this information were stored in pyproject.toml, since it is meta-information about the build system itself. We can either lobby to add that to the pyproject.toml build-system spec or possibly just add a setuptools-specific configuration option to pyproject.toml when we resolve #1515.

[nicoddemus]

Another situation reported by pytest users in pytest-dev/pytest#4770: python_requires is not taken in account when packages are installed to run python setup.py test.

This is causing some grief to Python 2.7 pytest users which execute python setup.py test because more-itertools version 6 no longer supports Python 2.7, although it correctly specifies python_requires>=3.4.

[pganssle]

@nicoddemus I think that setup.py test is essentially deprecated; there is pretty wide agreement in #931 that we should remove it in favor of tox, so I'm not sure we want to be actively fixing it when it breaks.

I don't know if it's a big deal to fix it, though. If it's easy enough to do we might as well do it, but on the other hand I think almost anything that hits an easy_install path has been largely treated as best effort and not made a high priority.

[nicoddemus]

Fair enough, thanks @pganssle! I think deprecating it would be a good start so people can move to more friendly and stable setups with tox. 👍

[VelorumS]

There is also something wrong with the install_requires.

For example: selenium 4.0.0b1 requires python 3.7, but when running this on python 3.6 we get selenium 4.0.0b1 installed anyway:

from setuptools import setup

setup(
    name="my package",
    py_modules=["mypackage"],
    install_requires=['selenium']
)