----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: devel(a)ovirt.org
Sent: Monday, April 27, 2015 5:42:55 PM
Subject: vdsm: python3 support?
Vdsm depends on Python 2, but the developers of Python 2 wants us (and
everybody else) to move to the slightly-different language of Python 3.
There is a lot to be fixed for this to happen:
- depency on libraries with no python3 port:
- mom
- cpopen
- m2crypto
- use of implicit relative imports, mostly in the storage package
- use of renamed/moved functions, methods and modules (e.g.
dict.iteritems, io.StringIO, itertools.izip)
- use of contextlib.nested
- unsafe unicode treatment
- and probably much more...
python 2 string was a mixture of bytes/unicode, now split on python 3.
We have low-level code (JSONRPC & co) which may want/need to carefully audit.
Fixing it all would take a long time, and may introduce regressions.
We
must perform it gradually.
The very first step is to use syntax that is compatible with both
languages, and make sure we do not regress on that front.
[...]
Strong +1
Can we agree about a flow for us developers which
will help not introducing (or at least minimizing) regressions?
Something like an automated test would be the best option I believe
(a-la make pep8/make pyflakes)
There are a few tools that could help, at least in theory, tox
comes first to mind (
https://pypi.python.org/pypi/tox) but adapting
VDSM to work seamlessly with tox can require a large amount of work.
I don't specifically advocate tox -I use and I like it, that's it-
anything else which helps is welcome too.
Bests,
--
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani