Adds output that reflects a package's supported Python interpreters #80
Conversation
| cat */PKG-INFO | python -c ' | ||
| import json, re, sys | ||
| match_classifier = re.compile( | ||
| r"\s*Classifier: Programming Language :: Python :: (\d+\.\d+)$" |
There was a problem hiding this comment.
a correct implementation needs to consider requires_python and the list of supported python versions of githubs setup_python
There was a problem hiding this comment.
i could argue that this component shouldn't serve for deferred metadata consistency validation and generally as well as particularly regarding the second concerns: the targeted application environment is the one where we want things to crash in order to fix upon. the provided outputs are supposed to be building blocks, afaik jq is available in the runner environment.
There was a problem hiding this comment.
The reason the version list should come from requires-python is that that list Will be what pip will consider/respect
The trove classifiers are neither complete nor under mandatory consideration
There was a problem hiding this comment.
Yeah, requires-python is the canonical metadata we ought to check. It would be a nice-to-have to raise an error, if it it contradicts the classifiers, but the classifiers are just a FYI.
That said there's the big question of how would we decide the upped Python version bound?
You get that from the classifiers which kinda made them an indicator of what the CI is checking against. But the supported upper bound would have to technically change whenever GitHub Actions add a new Python version?
There was a problem hiding this comment.
If no upper bound was given,then it's a good idea to get a failure as soon as a new python version gets added that fails
I'd consider known good upper bounds as out of scope for this one
|
frohes neues! as your requirements are different than mine, i'm closing this. |
Honestly, I don't think they are. There seems to be two things at play that sounds the same but aren't:
To me, it would make the most sense to use 1. to drive the CI and – and this doesn't have to be the same PR/step – checking if 1 and 2 are contradicting each other. Since it's possible to define quite intricate versions in 2, I'm not even sure how realistic that is. I remember e.g. most asyncio packages requiring a later 3.5 minor release due to asyncio bugs. |
honestly, i'm unsure whether i followed correctly until now.
my impression is that the difference was clear all the time.
i assume that you mean the respective trove classifiers with that?
i agree, because I do assume that all packages are supposed to be built and shipped with complete and correct metadata. (otherwise i consider it a bug that requires a patch release.)
here i attempted to express that this a valid (even important) concern, but also that this proposal here isn't trying to solve that. it should be part of a metadata validation unit.
my consideration still is that it isn't worth the effort, particularly weighed against the previous argument. if the above reflects a consensus, feel free to re-open this pr. |
|
Currently, the only consensus that is needed is mine. We can work on this and merge it and let #43 open for further thinking/working on problem 2. |
|
As project fmt fixes the python version list, I consider it a good enough source |
i think that addresses proposal #43 by @RonnyPfannschmidt that i liked.
let me know what you think should still be addressed.