On 2020-01-31 17:56:50 +0100 (+0100), Radosław Piliszek wrote:
Yeah, we had pyenv conversations with qa and infra folks.
For the auto-generated constraints updates we could just generate them on representative platforms in separate jobs (or a multi-platform multinode job, though that's just additional complexity for no real gain over multiple jobs).
OTOH, I don't think it would be that hard to get that PyPI info.
The main challenge I foresee with that is you'll need to reimplement pip's logic around identifying what the highest supported version of a package is for each interpreter you care about. It's more than just knowing what interpreters a particular package version supports.
Anyways, I believe we want to follow one u-c approach as multiple add the burden on user to use the proper one. [...]
There's also a hybrid option, where you generate per-interpreter constraints files but then merge them, and automatically add an environment marker anywhere there's a difference. That allows you to continue to rely on pip's existing ability to identify the latest supported version of a package for each interpreter. -- Jeremy Stanley