Open Stack

On Wed, Apr 13, 2022, at 11:29 AM, Marcin Juszkiewicz wrote:
> W dniu 13.04.2022 o 17:02, Matthew Thode pisze:
>>> I tracked down the regression to the upper constraint on setuptools. For
>>> example, stable/yoga has:
>>>
>>> setuptools===59.6.0;python_version=='3.6'
>>> setuptools===60.9.3;python_version=='3.8'
>>>
>>> It appears this is ignored in the py39 job so the job runs with the latest
>>> setuptools. Indeed, there were some releases between March 10 and March 24.
>>> I still have to figure out what changed in setuptools to cause this
>>> behaviour.
>>>
>>> Question for requirements maintainers: is this expected behaviour, or
>>> should upper constraints also include lines for python_version=='3.9' on
>>> yoga?
>
>> I plan on removing py36 and adding py39 constraints today or tomorrow.
>
> So we will have ones for 3.8, other ones for 3.9 and then for 3.10 too?
>
> Can we just do one set with "3.8 is minimal, if someone runs older then 
> it is their problem"?

I don't think doing that would be a good idea (or possible in all cases). The idea here is that we're always trying to use the newest possible package versions. If a dependency drops support for 3.8 then you get a 3.8 specific entry for that python version and another for 3.9/3.10 for the newer stuff. 

It is possible (and likely) that a dependency could drop 3.8 and have newer versions for 3.9. It is also possible that a dependency could have no versions that satisfy all of 3.8, 3.9, and 3.10. Basically you have to accept that there may be entries for any version of python that you support due to the way dependencies handle python support, and the desire to have up to date dependencies.

>
> 3.8  - Ubuntu 'focal' 20.04
> 3.9  - Debian 'bullseye' 11, CentOS Stream 9/RHEL 9 (and rebuilds)
> 3.10 - Ubuntu 'jammy' 22.04
>
> Those are "main" distributions OpenStack Zed runs on. We should have one 
> set with "python_version" limits used only when it is REALLY needed.