Added supported Python versions to package metadata

[andy-maier]

This PR addresses issue #1448

Details:

• Added the 'python_requires' argument to setup() to specify the supported Python versions in the package metadata. Installers such as pip depend on that, and there are issues such as pywin32 version 227 supports Python 3.8 but does not advertise that on Pypi #1448 when the installer does not have that information in the package.

[Avasam]

@mhammond

have to agree it doesn't seem like the original post is something that's actually an issue (at least if it was, it isn't anymore). It feels a bit like #2028 is trying to solve something different than what this issue describes.

By itself, this PR is still doing something worthwhile. And it would make sense to merge before the next release or minimum python version bump (#2207)

If @andy-maier feels like this addresses their issue, then I'd be happy to close #1448

Although there's a quick conflict to resolve first.

[mhammond]

By itself, this PR is still doing something worthwhile.

I'm interested to know what that is in concrete terms. Do you mean that currently, someone trying to use python3.5 -m pip install pywin32 would currently end up with a broken install and this fixes that? Or something else? I asked that question in #1448 too.

My main concern about this patch is that it seems error prone. What exactly happens if we fail to bump that in the future? How will be avoid bumping the min version to 3.8 but forgetting this exists? I'd feel slightly better about it if it was parsed from classifiers automatically.

If @andy-maier feels like this addresses their issue, then I'd be happy to close #1448

It seems impossible for this to solve that issue, right?

[Avasam]

Come to think of it, because only version-specific wheels are shipped, it's probably not possible to even do that.

python3.6 -m pip install pywin32==306
ERROR: Could not find a version that satisfies the requirement pywin32==306 (from versions: 222, 223, 224, 225, 226, 227, 228, 300, 301, 302, 303, 304, 305)
ERROR: No matching distribution found for pywin32==306

Should've tested again.

As for the original issue: Adding a version pin wouldn't have helped, up or down. If anything it might be too restrictive. I also don't see pywin32 shipping source distribution either anyway.

And even when it comes to classifiers, pywin32 can't promise to be working on a python version before it's out and tested. Nor can it backport adding wheels, updating classifier, updating python_requires, if a Python version just released that happens to build/work w/o breaking changes.

[Avasam]

In other words: Adding this today would change nothing, the 3.8+3.9 classifiers were forgotten until version 228.
The "fix" would be to edit the past releases to add the classifiers. But uh, doubt that'll happen.
So if you need pywin32 225, 226, or 227 exactly, you should pin that version in your project.

[andy-maier]

I am not arguing to fix older versions of pywin32. But future versions simply should follow what most packages on Pypi do: Declare the Python requirements in such a way that pip understands them. Pip understands the "python_requires" statement, but not the Trove classifiers.

Also, since pywin32 is a package that delivers Python version-specific compiled wheel files, it can only really support Python versions for which it provides a wheel file. Pip cannot install pywin32 on Python versions for which there is no wheel file.

For example, pywin32 version 306 added wheel files for Python 3.12. If a user is using pywin32 version 303 on Python 3.12, pip will try to install it (due to lack of a useable Python requirement in the package metadata), and will fail because a wheel file is not available (That happened in our pywbem project, see this log file). If pywin32 declared the Python versions for which it provides wheel files, pip would not even try version 303 on Python 3.12. That has the same net effect for the user (pywin32 303 cannot be used on Python 3.12), but pip provides a much clearer error message than when it attempts the install and then fails during install.

In the previous version of this PR, I did not consider the fact that pip depends on the presence of wheel files. I have just updated the PR to accommodate that, and have also updated the Python versions to what pywin32 version 306 supports.

PS: I tried to find a recommendation for adding python_requires, but so far I could only find its description: https://setuptools.pypa.io/en/latest/userguide/dependency_management.html#python-requirement

[mhammond]

For example, pywin32 version 306 added wheel files for Python 3.12. If a user is using pywin32 version 303 on Python 3.12, pip will try to install it (due to lack of a useable Python requirement in the package metadata), and will fail because a wheel file is not available

Can you please elaborate here? How exactly would this happen? I understand that if someone manually downloads pywin32-306-cp37-cp37m-win_amd64.whl and then tells a 3.21 version of pip to install it things might get a little upset with a less than ideal message - is that what is happening here? Is it true that someone just running pip the "expected" way can never hit this?