setuptools could respect python_requires

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.

[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. 👍

[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.