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... 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. The remaining bit is our usages of raise E, V, T statement, which has been dropped in PEP-3109. https://gerrit.ovirt.org/#/c/40214/ suggests to replace it with six.reraise(), which adds a new run-time dependency to Vdsm. https://gerrit.ovirt.org/#/c/40215/ adds an attempt to python3-compile all vdsm code, so that we do not introduce new python2-only code. Please approve/comment!
----- Original Message -----
From: "Dan Kenigsberg" <danken@redhat.com> To: devel@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
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)
I think https://gerrit.ovirt.org/40215 address this
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.
Tox is super cool, we should use it. Nir
participants (3)
-
Dan Kenigsberg -
Francesco Romani -
Nir Soffer