Python 3.9 is here in Debian Sid
Hi there! Matthias Klose decided that uploading Python 3.9 on the 14th of this month (yes, the same day of the OpenStack release) would be fun. I am now really having fun ... fixing bugs! :) What's not so funny for me, is that some key packages like Greenlet or lxml aren't built yet for Python 3.9, even though they should. As a consequence, I just need to wait to be able to upload to Unstable. So this will delay my usual announcement for the release GA in Debian (even though the unofficial Victoria repo for Buster is ready and I could spawn VMs on Buster + Victoria). Anyways, all of this will settle slowly. Though Python 3.9 is here to stay, and to soon reach Ubuntu as well (it's planned for the next release). It'd be nice if projects were starting to investigate gating on Python 3.9 as early as possible. As much as I can tell, there's not so many issues to fix. The first one I fixed is here: https://review.opendev.org/758237 but I don't expect much more, and hopefully, I'll be able to propose more patch as I find the issues. Must we wait until Python 3.9 reaches Ubuntu to enable gating in the OpenStack projects? FYI, I do expect Victoria to run over Python 3.9 in Bullseye. Please don't reply with the usual "Victoria doesn't support it", because that's irrelevant. I'm fine with backporting patches, as long as they also exist in Wallaby. Cheers, Thomas Goirand (zigo)
On Thu, Oct 15, 2020 at 10:59 AM Thomas Goirand <zigo@debian.org> wrote:
Hi there!
Matthias Klose decided that uploading Python 3.9 on the 14th of this month (yes, the same day of the OpenStack release) would be fun. I am now really having fun ... fixing bugs! :)
What's not so funny for me, is that some key packages like Greenlet or lxml aren't built yet for Python 3.9, even though they should. As a consequence, I just need to wait to be able to upload to Unstable. So this will delay my usual announcement for the release GA in Debian (even though the unofficial Victoria repo for Buster is ready and I could spawn VMs on Buster + Victoria).
Anyways, all of this will settle slowly. Though Python 3.9 is here to stay, and to soon reach Ubuntu as well (it's planned for the next release).
It'd be nice if projects were starting to investigate gating on Python 3.9 as early as possible. As much as I can tell, there's not so many issues to fix. The first one I fixed is here:
https://review.opendev.org/758237
but I don't expect much more, and hopefully, I'll be able to propose more patch as I find the issues.
Must we wait until Python 3.9 reaches Ubuntu to enable gating in the OpenStack projects?
3.9 is already available in Ubuntu 20.04 (albeit at an RC but it will be updated) so that should not block enabling test gates. Cheers James
On Thu, 2020-10-15 at 11:32 +0100, James Page wrote:
On Thu, Oct 15, 2020 at 10:59 AM Thomas Goirand <zigo@debian.org> wrote:
Hi there!
Matthias Klose decided that uploading Python 3.9 on the 14th of this month (yes, the same day of the OpenStack release) would be fun. I am now really having fun ... fixing bugs! :)
What's not so funny for me, is that some key packages like Greenlet or lxml aren't built yet for Python 3.9, even though they should. As a consequence, I just need to wait to be able to upload to Unstable. So this will delay my usual announcement for the release GA in Debian (even though the unofficial Victoria repo for Buster is ready and I could spawn VMs on Buster + Victoria).
Anyways, all of this will settle slowly. Though Python 3.9 is here to stay, and to soon reach Ubuntu as well (it's planned for the next release).
It'd be nice if projects were starting to investigate gating on Python 3.9 as early as possible. As much as I can tell, there's not so many issues to fix. The first one I fixed is here:
https://review.opendev.org/758237
but I don't expect much more, and hopefully, I'll be able to propose more patch as I find the issues.
Must we wait until Python 3.9 reaches Ubuntu to enable gating in the OpenStack projects?
3.9 is already available in Ubuntu 20.04 (albeit at an RC but it will be updated) so that should not block enabling test gates. rhel 9 wont be around for quite a while yet but i think its also going to be based on 3.9 so having early gating on 20.04 would be quite useful as i think we should be trying to make 3.9 supported in wallaby
the next majory redhat openstack release will be based on wallaby and that is likely to be rhel9 based so having rhel 9 compatiablw will help all the major distos be able to ship wallaby when it is released
Cheers
James
3.9 is already available in Ubuntu 20.04 (albeit at an RC but it will be updated) so that should not block enabling test gates.
Cheers
James
It might be good to add a non-voting "openstack-tox-py39" job to the wallaby template: https://opendev.org/openstack/openstack-zuul-jobs/src/branch/master/zuul.d/p... All official projects should be running with that template now, so it would be an easy way to get jobs going and start to see what issues are uncovered. Sean
On 10/15/20 4:21 PM, Sean McGinnis wrote:
3.9 is already available in Ubuntu 20.04 (albeit at an RC but it will be updated) so that should not block enabling test gates.
Cheers
James
It might be good to add a non-voting "openstack-tox-py39" job to the wallaby template:
https://opendev.org/openstack/openstack-zuul-jobs/src/branch/master/zuul.d/p...
All official projects should be running with that template now, so it would be an easy way to get jobs going and start to see what issues are uncovered.
Sean
I also think it'd be nice to have non-voting jobs detecting deprecated stuff. For example, a quick grep shows that a lot of projects are still using collections.Mapping instead of collections.abc.Mapping (which is to be removed in Python 3.10, according to the 3.9 release notes). Would there be a way to get our CI report these issues earlier? Cheers, Thomas Goirand (zigo)
On 2020-10-16 10:21:34 +0200 (+0200), Thomas Goirand wrote: [...]
I also think it'd be nice to have non-voting jobs detecting deprecated stuff. For example, a quick grep shows that a lot of projects are still using collections.Mapping instead of collections.abc.Mapping (which is to be removed in Python 3.10, according to the 3.9 release notes). Would there be a way to get our CI report these issues earlier?
They're going to all explode, at least until PBR gets some more changes merged and released to stop doing deprecated things. I've been slowly working my way through testing simple PBR-using projects with PYTHONWARNINGS=error (instead of =default::DeprecationWarning) and fixing or noting the issues I encounter. Up until recently, a number of its dependencies were also throwing deprecation warnings under 3.9, but now I think we're down to just a couple of remaining fixes pending. We didn't want to try to rush in a new PBR release until Victoria was wrapped up, but now I think we can finish this fairly soon. -- Jeremy Stanley
On 10/16/20 3:59 PM, Jeremy Stanley wrote:
On 2020-10-16 10:21:34 +0200 (+0200), Thomas Goirand wrote: [...]
I also think it'd be nice to have non-voting jobs detecting deprecated stuff. For example, a quick grep shows that a lot of projects are still using collections.Mapping instead of collections.abc.Mapping (which is to be removed in Python 3.10, according to the 3.9 release notes). Would there be a way to get our CI report these issues earlier?
They're going to all explode, at least until PBR gets some more changes merged and released to stop doing deprecated things. I've been slowly working my way through testing simple PBR-using projects with PYTHONWARNINGS=error (instead of =default::DeprecationWarning) and fixing or noting the issues I encounter. Up until recently, a number of its dependencies were also throwing deprecation warnings under 3.9, but now I think we're down to just a couple of remaining fixes pending. We didn't want to try to rush in a new PBR release until Victoria was wrapped up, but now I think we can finish this fairly soon.
Great, thanks for this work. Thomas
On 2020-10-16 13:59:10 +0000 (+0000), Jeremy Stanley wrote:
On 2020-10-16 10:21:34 +0200 (+0200), Thomas Goirand wrote: [...]
I also think it'd be nice to have non-voting jobs detecting deprecated stuff. For example, a quick grep shows that a lot of projects are still using collections.Mapping instead of collections.abc.Mapping (which is to be removed in Python 3.10, according to the 3.9 release notes). Would there be a way to get our CI report these issues earlier?
They're going to all explode, at least until PBR gets some more changes merged and released to stop doing deprecated things. I've been slowly working my way through testing simple PBR-using projects with PYTHONWARNINGS=error (instead of =default::DeprecationWarning) and fixing or noting the issues I encounter. Up until recently, a number of its dependencies were also throwing deprecation warnings under 3.9, but now I think we're down to just a couple of remaining fixes pending. We didn't want to try to rush in a new PBR release until Victoria was wrapped up, but now I think we can finish this fairly soon.
Just to follow up, at this point I think we've merged and released everything PBR needs for this, but now it's become apparent we're blocked on Setuptools behavior. In particular, any call into setuptools/command/build_py.py unconditionally tries to import setuptools.lib2to3_ex.Mixin2to3 even if the build is not going to use lib2to3, so this will automatically raise a SetuptoolsDeprecationWarning if run with PYTHONWARNINGS=error. I expect we're stuck until https://github.com/pypa/setuptools/issues/2086 gets resolved, so this is the next thing to work on if anyone has time (it may take me a while to get around to submitting a PR as I expect they're going to want a very thorough cleanup). -- Jeremy Stanley
On Thu, Oct 15, 2020 at 10:23 AM Sean McGinnis <sean.mcginnis@gmx.com> wrote:
3.9 is already available in Ubuntu 20.04 (albeit at an RC but it will be updated) so that should not block enabling test gates.
Cheers
James
It might be good to add a non-voting "openstack-tox-py39" job to the wallaby template:
https://opendev.org/openstack/openstack-zuul-jobs/src/branch/master/zuul.d/p...
All official projects should be running with that template now, so it would be an easy way to get jobs going and start to see what issues are uncovered.
Sean
Thanks for the suggestion. I have a review up for this at https://review.opendev.org/#/c/758813/. It also adds non-voting py39 jobs for wallaby. If there's any chance of adding py39 as a supported run-time at this point for wallaby [1] please let me know. [1] https://review.opendev.org/#/c/743847/ Thanks, Corey
participants (7)
-
Corey Bryant
-
James Page
-
Jeremy Stanley
-
Sean McGinnis
-
Sean Mooney
-
Thomas Goirand
-
Thomas Goirand