-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can pyreadiness look at more than the classifiers? #18
Comments
Thanks for the issue! Yes, this should be possible, and I would merge a PR that adds this. |
What about packages which have an open-ended |
Here's my reasoning for using only It seems that other projects have come to the same conclusion, that keeping the classifiers up to date is noisy/busy work that doesn't really benefit actively maintained/compatible projects. We ran our tests against 3.10.0rc months ago and addressed any test failures then. I don't think we actually had to make any new releases, just fix some tests. It's sort of weird though, because technically, |
I do see at the top of the site that it says "don't explicitly support Python 3.10" (emphasis added). To indicate the potential inacurracy of checking
|
Are there any projects in the top 360 that are known to be unmaintained and break with 3.10? Perhaps a list of |
This makes sense to me.
Seems unlikely, but it is hard to gauge whether a project is maintained or not. |
312 of the top 360 have a 2.x or 3.x classifier, 87%.
Yes, isodate is one. There are others ( |
To get an idea of how many packages don't yet support Python 3.10, I tried installing them all with pip. Looking at the 319 packages not explicitly declaring support for Python 3.10 (on Sunday), these failed to install. Ubuntu:
macOS:
Windows:
In total, 42 unique packages. Of these 42: 27 have
Trusting an open-ended I can imagine someone wanting to work with pandas, SciPy or TensorFlow checking this site and seeing it green for 3.10, but then confused why it won't even install. And successful installation doesn't necessarily mean successfully running on Python 3.10. I expect more outside this list have runtime incompatibilities as well, such as isodate. |
There are other metrics and heuristics that could be added. For example, check if a wheel is available for the given Python version exists, and treat that the same as a classifier. Skimming the list, it looks like most that don't install would probably have other install requirements, such as compilation toolchains. I'd also treat having no platform wheels and only a generic wheel as satisfying that metric. I'd like to hear more ideas for solutions to the issue. I strongly prefer not having to update classifiers on my projects, for the reasons stated above. So they will forever be listed as "not Python 3.X ready" under the current metric, which is unfortunate. |
FYI, the My suggestion: mark any packages that do not have minor version classifiers in a different color. Also check for wheels, and anything shipping 3.11 binary wheels get a green color too (I think this is easier with the json API? Haven't checked). This still misses some Python libraries, but the colors + check for wheels would really help. Some examples that are still not 3.10 compatible according to the current logic: setuptools, six, importlib-metadata, zipp, click, flask, beautifulsoup4, and more. FYI, you can't use Footnotes
|
Here's my concrete suggestion: Three colors: Green + checkmark for N classifier or N binary wheel. Red + X for neither of these but N-1 classifier or N-1 binary wheel present1. And white + question mark otherwise. Didn't check to see if any of those have ABI3 wheels, those are harder to place. 14 packages2 would be added by including wheels in addition to classifiers for 3.11. Only 25 (total) packages provide 3.10 wheels but not 3.11, compared to 36 that provide 3.11 wheels. This doesn't turn I can implement that if it sounds reasonable. Footnotes
|
I made this chart that shows the number of packages that support a particular Python version based on binary wheels' filenames (limited to 3.9-3.11 - I wanted a visual aid to help think about whether to upgrade a project I'm involved with to 3.9 or 3.10). The discussion here was helpful for this, thank you. Caveats & notes: The underlying script makes use of the
For the chart, I adjusted this condition to "neither of these but a classifier for a different minor version present or a binary wheel for an earlier minor version present". Although the numbers are very few, some packages, like backports.zoneinfo, legitimately do not support the last few Python versions, and if we look at only the previous version (N-1), they get classified as 'maybe' / 'white + question mark' rather than 'no' / 'red + x'. |
The JSON API includes the
requires_python
metadata for each package. If that were included, more packages would be marked as ready for 3.10 (for example).As one data point, pip will happily install Jinja2 into 3.10, but Jinja2 is marked as not ready for 3.10 because it doesn't mention the 3.10 classifier. It has
requires_python: ">=3.6"
and so could be marked as ready.The text was updated successfully, but these errors were encountered: