mhammond
pywin32 version 227 supports Python 3.8 but does not advertise that on Pypi
Pywin32 version 225 added support for Python 3.8 by providing the corresponding wheel archives.
However, the Python versions advertised in the setup.py files only go as far up as Python 3.7. That can also be seen by looking at the Pypi representation for pywin version 225, 226 or 227, which shows 2.7, 3.5, 3.6, 3.7, but not 3.8.
Since pip takes the registered Python versions on pypi with precedence over the provided wheel archives on Pypi, it cannot install pywin32 at all on Python 3.8.
Sorry, I have to correct myself: pywin32 version 227 is in fact installable on Windows with Python 3.8, but the Pypi site still does not show 3.8 as supported. So it is a less urgent problem than I thought, but it should still be made consistent.
The strange thing is that pywin32 version 225 on Pypi also has the Python 3.8 wheel files for downloading, and also does not advertise Python 3.8, but cannot be installed using pip on Python 3.8. See our Appveyor CI failure showing this: https://ci.appveyor.com/project/andy-maier/pywbem/builds/29183612/job/astn2h6cmoljixqg
This old and unresolved problem caused me some extra hours of work today, because I simply did not remember it. I finally provided a fix for it in PR #2028.
Thanks - but I don't understand the problem you are facing. pypi tells me it's available for 3.6 to 3.11 (both in the header and "classifiers" section) and pip installs it fine in later ones for me.
pypi tells me it's available for 3.6 to 3.11 (both in the header and "classifiers" section)
@mhammond According to this documentation, even if it shows in the classifiers like shown below, that's visual only and adding python-requires like #2028 could still be beneficial to ensure that pip does not try to install a version of pywin32 that's too recent for the Python version
https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#classifiers
Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the python_requires argument.
https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#python-requires
If your project only runs on certain Python versions, setting the python_requires argument to the appropriate PEP 440 version specifier string will prevent pip from installing the project on other Python versions. [...]
I don't understand how #2028 will help anyone other than a small minority of users - it wants to specify python_requires = ">=3.7", which isn't going to help anyone mismatching versions 3.7 and later. Sure, it will stop someone on 3.5 trying to install a 3.8 version, but 3.7, 3.9, 3.10 and 3.11 all will still be "allowed" by that scheme even though they will not work.
Maybe a version of that which specified the exact version would help?
But I'm still trying to understand how this situation. The very first comment doesn't imply they somehow got the wrong version installed, but instead that they believed it was not available at all for 3.8. I don't see how #2028 solves that?
I'm also assuming most users get this from pypi, which does appear to do the right thing with versions - so I guess #2028 isn't going to help them - who will it help? What error do you get today if you do try and explicitly mis-match versions?
🤷 I 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.
And since I'm not affected by #2028 , nor have I tried to replicate it, I'm just sharing documentation for posterity at this point.