On 05/06/18 16:38, Doug Hellmann wrote:
Excerpts from Zane Bitter's message of 2018-06-05 15:55:49 -0400:
We've talked a bit about migrating to Python 3, but (unless I missed it)
not a lot about which version of Python 3. Currently all projects that
support Python 3 are gating against 3.5. However, Ubuntu Artful and
Fedora 26 already ship Python 3.6 by default. (And Bionic and F28 have
been released since then.) The one time it did come up in a thread, we
decided it was blocked on the availability of 3.6 in Ubuntu to run on
the test nodes, so it's time to discuss it again.
AIUI we're planning to switch the test nodes to Bionic, since it's the
latest LTS release, so I'd assume that means that when we talk about
running docs jobs, pep8 &c. with Python3 (under the python3-first
project-wide goal) that means 3.6. And while 3.5 jobs should continue to
work, it seems like we ought to start testing ASAP with the version that
users are going to get by default if they choose to use our Python3
packages.
The list of breaking changes in 3.6 is quite short (although not zero),
so I wouldn't expect too many roadblocks:
https://docs.python.org/3/whatsnew/3.6.html#porting-to-python-3-6
I think we can split the problem into two parts:
* How can we detect any issues ASAP.
Would it be sane to give all projects with a py35 unit tests job a
non-voting py36 job so that they can start fixing any issues right away?
Like this: https://review.openstack.org/572535
That seems like a good way to start.
Maybe we want to rename that project template to openstack-python3-jobs
to keep it version-agnostic?
You mean the 35_36 one? Actually, let's discuss this on the review.
* How can we ensure every project fixes any issues and migrates to
voting gates, including for functional test jobs?
Would it make sense to make this part of the 'python3-first'
project-wide goal?
Yes, that seems like a good idea. We can be specific about the version
of python 3 to be used to achieve that goal (assuming it is selected as
a goal).
The instructions I've been putting together are based on just using
"python3" in the tox.ini file because I didn't want to have to update
that every time we update to a new version of python. Do you think we
should be more specific there, too?
That's probably fine IMHO. We should just be aware that e.g. when
distros start switching to 3.7 then people's local jobs will start
running in 3.7.
For me, at least, this has already been the case with 3.6 - tox is now
python3 by default in Fedora, so e.g. pep8 jobs have been running under
3.6 for a while now. There were a *lot* of deprecation warnings at first.
Doug
cheers,
Zane.
(Disclaimer for the conspiracy-minded: you might assume that I'm
cleverly concealing inside knowledge of which version of Python 3 will
replace Python 2 in the next major release of RHEL/CentOS, but in fact
you would be mistaken. The truth is I've been too lazy to find out, so
I'm as much in the dark as anybody. Really. Anyway, this isn't about
that, it's about testing within upstream OpenStack.)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
