Add warning if python classifiers do not match the running version

[xavfernandez]

I'm looking for feedback before starting to add tests :)

cc @pypa/pip-committers

---

This change is

[xavfernandez]

The kind of warning it produces is:

$ pip install django
DEPRECATION: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. A future version of pip will drop support for Python 2.6
Collecting django
  Downloading https://pypi.somewhere.org/root/pypi/+f/849/713c2687bbd57/Django-1.9.5-py2.py3-none-any.whl (6.6MB)
    100% |████████████████████████████████| 6.6MB 108kB/s 
  Django is advertised as supporting Python 2.7, Python 3.4, Python 3.5 but not Python 2.6
Installing collected packages: django
Successfully installed django-1.9.5

[pfmoore]

Do we have any feel for how accurate/well-maintained the Python version classifier is, in practice? This could be annoyingly noisy if the data is unreliable. Also, it will produce a flurry of warnings when Python 3.6 is released, in the period before projects release a new version which updates the classifiers to include 3.6.

I do see the value, though, and it's hard to see how the classifiers will become any more accurate unless we do something like this.

I guess I'm +0 on this, but would like a way to turn it off (for the "new release of Python" situation).

[jamadden]

I know that the zope projects take it pretty seriously, but I also know it takes us awhile to get the dozens of projects updated. We're just recently caught up to 3.5 in git, and most of those haven't been released to PyPI (and usually aren't just for a classifier change IIUC).

[Ivoz]

I think the classifiers are badly misused here, and that misuse should not be turned into a formal misuse by placing code functionality upon them.

Really the information should be a static dependency - python_version >= '3.3' for example (Note how that does away with having to list an ever growing line of 3.x releases in classifiers?). Shoe-horning what are essentially inflexible tags is not a great idea.

Only reason we've been using them is because they were nice static metadata, whereas historically install_requires has been something to be figured out at build and install time, making it next to imposssible to parse / read statically. As peps 426 / 440 are adopted should fix this though.

[xavfernandez]

Also, it will produce a flurry of warnings when Python 3.6 is released, in the period before projects release a new version which updates the classifiers to include 3.6.

if (minor_versions and sys.version_info[0:2] not in minor_versions and
        sys.version_info[0:2] < max(minor_versions)):

should be taking care of this:
we expect libraries advertising support with 3.5 to keep working with 3.6.

[xavfernandez]

Do we have any feel for how accurate/well-maintained the Python version classifier is, in practice? This could be annoyingly noisy if the data is unreliable.

I guess it is quite unmaintained and one of the goal of this PR would be to show the lack of maintenance: either you remove the classifiers or you keep them up-to-date.

And of course, I would also add a --no-classifier-check option to easily disable this noise.

[dstufft]

I'm fairly concerned about using the classifiers for this purpose. A lot of projects have unmaintained classifiers and I think it needlessly "punishes" (for lack of a better word) these projects. Some of these projects may not have any reason to cut a new release when a new version of Python exists except to add a new classifier... which seems counter productive to me?

I think if we want a feature like this (and I like the idea behind the feature!) we'd be better off to expose a way to add the Requires-Python metadata in setuptools so that A) It gets exposed in PyPI and B) it's now in the metadata and pip can read that and act on it. Using that, we could even get a bit more strict in how this is implemented and bail out if we attempt to install something with a Requires-Python that doesn't match (probably without some sort of --force flag).

[pfmoore]

On reflection, I agree with @Ivoz and @dstufft - while it would be nice to have some validation that installed packages are supported on the version of Python you are using, the classifiers are not well enough maintained, or flexible enough, to serve this purpose. Changing them from descriptive-only to having an install-time impact (even if it's only a warning) is going to cause more pain than it gains.

Instead, I think we need to use a different (new) field. It's possible that Requires-Python would work, although in principle that's mandatory according to Metadata 1.2, and yet as far as I know is rarely if ever used at the moment due to lack of tool support.

Some questions:

1. Would the field be mandatory? If not, how would we encourage projects to add it? What's the benefit for the project to do so? The most obvious benefit would be to have a way of flagging "not supported on the following older versions of Python" so maybe an Incompatible-Python entry would be better?
2. Realistically, if it's a new field, will projects use it? There's a history of projects only providing the bare minimum of metadata - as I noted, Requires-Python is technically mandatory, but in practice not used.

I guess the real question is, are projects asking for this capability? While I like the idea in the abstract, if the users don't care, is it going to be worthwhile to add?

[xavfernandez]

New PR based on Requires-Python: #3846