The recent discussions mentioning the Programming Language :: Python :: 3.xx trove classifiers (mostly from the who supports 3.13 yet? conversation where people are relying on them to gather machine readable data) got me looking at my own packages.
About half of them are small, narrowly scoped, low maintenance projects which have worked out of the box for the last few new Python versions and I haven’t had to release them for years so, despite being tested against 3.13-dev, they only allegedly support up to Python 3.9 or up to 3.10 according to the classifiers that PyPI is displaying.
It’s a minor issue but I imagine that it happens to quite a lot of projects/maintainers. I think I have 3 options here:
Ignore the minor piece of misinformation and hope no one misinterprets it as a sign that the projects are abandoned
Do an otherwise pointless release just to get wheels with the updated classifiers onto PyPI
Stop using the Python version classifiers for low churn projects since they’re wrong more often than they’re right
I got halfway through doing option 3 before I decided to hear what other people think first? What (if anything) do people use those classifiers for and how would they be affected by either option 1 or option 3?
I don’t think I do this myself, but if you expect your project will be compatible with all Python 3 versions, just put the Programming Language :: Python :: 3 classifier and don’t get any more specific?
It’d be nice if the trove classifier was used to mean something like “minimum supported version”, indicating what syntax is needed (e.g. I’m using match statements, or := operators, or whatever) and higher versions should be supported.
If a new Python version arrives and something in the old package is deprecated, then there needs to be a new release anyway, and the classifier can be updated.
I don’t think there’s a way to just adopt that convention, though–it’d probably require removing these classifiers and adding a new one.
Thanks for testing against prerelease Pythons! I would add the classifier at the time you get the tests green, but continue to make releases as per your usual schedule.
I wouldn’t think reasonable folks would interpret the package as being abandoned. I think it’s kind of silly to think something is abandoned and switch without a) checking the actual project (which in your case would have active commits demonstrating testing on new Python), b) having a direct unmet need (needing something merged/released). And enough people don’t bother doing minor version classifiers or let them get stale that there’s plenty of company.
That said, I guess if your last release was years ago and your last classifier was like 3.6, I’d probably assume that your software is either done or abandoned. And it’s fine for software to be done. And it’s also fine to make non-functional releases at a cadence of your choice as a way to communicate liveness and ongoing testing to users.
Essentially, there is a check for valid classifiers and older distributions package an old version of trove-classifiers so packages that wish to indicate support for new Python versions fail at build time.
This does sound like Hatchling needs to depend on a recent trove-classifiers if it’s going to require a package’s classifiers all exist in trove-classifiers.
It doesn’t sound like a problem unique to version classifiers – I expect Hatchling could also fail if I’m using a Framework :: My Cool New Framework that was added this year but the distro still has a years old trove-classifiers.
for some reason I thought there was a difference in granularity between the two, but nobody is tagging their package for a bugfix release.