[all][requirements][qa] zipp failing py3.5 again
Folks, we are running circles here. [1] merged breaking zipp again for py3.5 The script which generates these proposals needs to learn python version constraints. Reproposed [2]. [1] https://review.opendev.org/705128 [2] https://review.opendev.org/705184 -yoctozepto
On 2020-01-31 11:17:10 +0100 (+0100), Radosław Piliszek wrote: [...]
The script which generates these proposals needs to learn python version constraints. [...]
It might be possible to crawl the PyPI API and try to apply matching environment markers, but I'm starting to think we just need separate constraints lists per interpreter version instead (and then we can generate them by running the current script from each interpreter). -- Jeremy Stanley
On 20-01-31 10:38:58, Jeremy Stanley wrote:
On 2020-01-31 11:17:10 +0100 (+0100), Radosław Piliszek wrote: [...]
The script which generates these proposals needs to learn python version constraints. [...]
It might be possible to crawl the PyPI API and try to apply matching environment markers, but I'm starting to think we just need separate constraints lists per interpreter version instead (and then we can generate them by running the current script from each interpreter). -- Jeremy Stanley
I think that would require all those pythons being installed. Personally I only have access to 2.7(for now) and 3.6-3.9, so no 3.4 or 3.5 locally at least. Not sure what the availability is for all those pythons for gate. Maybe pyenv can help? https://github.com/pyenv/pyenv -- Matthew Thode
Yeah, we had pyenv conversations with qa and infra folks. OTOH, I don't think it would be that hard to get that PyPI info. Anyways, I believe we want to follow one u-c approach as multiple add the burden on user to use the proper one. -yoctozepto pt., 31 sty 2020 o 17:46 Matthew Thode <mthode@mthode.org> napisał(a):
On 20-01-31 10:38:58, Jeremy Stanley wrote:
On 2020-01-31 11:17:10 +0100 (+0100), Radosław Piliszek wrote: [...]
The script which generates these proposals needs to learn python version constraints. [...]
It might be possible to crawl the PyPI API and try to apply matching environment markers, but I'm starting to think we just need separate constraints lists per interpreter version instead (and then we can generate them by running the current script from each interpreter). -- Jeremy Stanley
I think that would require all those pythons being installed. Personally I only have access to 2.7(for now) and 3.6-3.9, so no 3.4 or 3.5 locally at least. Not sure what the availability is for all those pythons for gate. Maybe pyenv can help? https://github.com/pyenv/pyenv -- Matthew Thode
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
participants (3)
-
Jeremy Stanley
-
Matthew Thode
-
Radosław Piliszek