[openstack-dev] [all][python3][tc][infra] Python 3.6

Zane Bitter zbitter at redhat.com
Tue Jun 5 20:48:00 UTC 2018

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list