We've decided that python-3.5 is the minimum python version (#17270)

This commit is contained in:
Toshio Kuratomi 2016-08-29 09:12:37 -07:00 committed by GitHub
parent fa804125b5
commit b8a8027b7d
5 changed files with 29 additions and 38 deletions

View file

@ -15,8 +15,6 @@ matrix:
python: 2.6
- env: TARGET=sanity TOXENV=py27
python: 2.7
- env: TARGET=sanity TOXENV=py34
python: 3.4
- env: TARGET=sanity TOXENV=py35
python: 3.5
- env: TARGET=sanity TOXENV=py24

View file

@ -93,7 +93,7 @@ MOCK_CFG ?=
NOSETESTS ?= nosetests
NOSETESTS3 ?= nosetests-3.4
NOSETESTS3 ?= nosetests-3.5
########################################################

View file

@ -13,42 +13,41 @@ factors that make it harder to port them than most code:
Which version of Python-3.x and which version of Python-2.x are our minimums?
=============================================================================
The short answer is Python-3.4 and Python-2.4 but please read on for more
The short answer is Python-3.5 and Python-2.4 but please read on for more
information.
For Python-3 we are currently using Python-3.4 as a minimum. However, no long
term supported Linux distributions currently ship with Python-3. When that
occurs, we will probably take that as our minimum Python-3 version rather than
Python-3.4. Thus far, Python-3 has been adding small changes that make it
more compatible with Python-2 in its newer versions (For instance, Python-3.5
added the ability to use percent-formatted byte strings.) so it should be more
pleasant to use a newer version of Python-3 if it's available. At some point
this will change but we'll just have to cross that bridge when we get to it.
For Python-3 we are currently using Python-3.5 as a minimum on both the
controller and the managed nodes. This was chosen as it's the version of
Python3 in Ubuntu-16.04, the first long-term support (LTS) distribution to
ship with Python3 and not Python2. Much of our code would still work with
Python-3.4 but there are always bugfixes and new features in any new upstream
release. Taking advantage of this relatively new version allows us not to
worry about workarounds for problems and missing features in that older
version.
For Python-2 the default is for modules to run on Python-2.4. This allows
users with older distributions that are stuck on Python-2.4 to manage their
machines. Modules are allowed to drop support for Python-2.4 when one of
their dependent libraries require a higher version of python. This is not an
invitation to add unnecessary dependent libraries in order to force your
module to be usable only with a newer version of Python. Instead it is an
acknowledgment that some libraries (for instance, boto3 and docker-py) will
only function with newer Python.
For Python-2, the default is for the controller to run on Python-2.6 and
modules to run on Python-2.4. This allows users with older distributions that
are stuck on Python-2.4 to manage their machines. Modules are allowed to drop
support for Python-2.4 when one of their dependent libraries require a higher
version of python. This is not an invitation to add unnecessary dependent
libraries in order to force your module to be usable only with a newer version
of Python. Instead it is an acknowledgment that some libraries (for instance,
boto3 and docker-py) will only function with newer Python.
.. note:: When will we drop support for Python-2.4?
The only long term supported distro that we know of with Python-2.4 is
RHEL5 (and its rebuilds like CentOS5) which is supported until April of
2017. We will likely end our support for Python-2.4 in modules in an
Ansible release around that time. We know of no long term supported
distributions with Python-2.5 so the new minimum Python-2 version will
likely be Python-2.6. This will let us take advantage of the
forwards-compat features of Python-2.6 so porting and maintainance of
Python-2/Python-3 code will be easier after that.
2017. Whatever major release we make in or after April of 2017 (probably
2.4.0) will no longer have support for Python-2.4 on the managed machines.
Previous major release series's that we support (2.3.x) will continue to
support Python-2.4 on the managed nodes.
.. note:: Ubuntu 16 LTS ships with Python 3.5
We know of no long term supported distributions with Python-2.5 so the new
minimum Python-2 version will be Python-2.6. This will let us take
advantage of the forwards-compat features of Python-2.6 so porting and
maintainance of Python-2/Python-3 code will be easier after that.
We have ongoing discussions now about taking Python3-3.5 as our minimum
Python3 version.
Supporting only Python-2 or only Python-3
=========================================
@ -152,7 +151,7 @@ dealing with file permissions. (With file permissions a user may be feeding
the mode into another program or to another module which doesn't understand
the python syntax for octal numbers. ``[zero][digit][digit][digit]`` is
understood by most everything and therefore the right way to express octals in
these cisrcumstances.
these circumstances.
Bundled six
-----------

View file

@ -51,8 +51,6 @@ matrix:
python: 2.6
- env: TEST=sanity INSTALL_DEPS=1 TOXENV=py27
python: 2.7
- env: TEST=sanity INSTALL_DEPS=1 TOXENV=py34
python: 3.4
- env: TEST=sanity INSTALL_DEPS=1 TOXENV=py35
python: 3.5

View file

@ -1,8 +1,5 @@
[tox]
envlist = py26,py27,py34,py35
[testenv:py34]
deps = -r{toxinidir}/test/utils/tox/requirements-py3.txt
envlist = py26,py27,py35
[testenv:py35]
deps = -r{toxinidir}/test/utils/tox/requirements-py3.txt
@ -14,7 +11,6 @@ commands =
python --version
py26: python -m compileall -fq -x 'test/samples|contrib/inventory/vagrant.py' lib test contrib
py27: python -m compileall -fq -x 'test/samples' lib test contrib
py34: python -m compileall -fq -x 'test/samples|lib/ansible/modules' lib test contrib
py35: python -m compileall -fq -x 'test/samples|lib/ansible/modules' lib test contrib
make tests