[python3 support] Investigate what is needed

[sbellem]

Given the various specialized dependencies, especially the cryptographic ones, this issue is simply concerned with evaluating how feasible it would be to port HoneyBadgerBFT to Python 3 in a reasonable time frame.

The result of the evaluation will be documented here in this issue.

blockers

UPDATE: No more blockers. zfec now supports Python 3 -- PR https://github.com/tahoe-lafs/zfec/pull/4 was merged.

zfec does not support Python 3 at the moment (related issue: https://github.com/tahoe-lafs/zfec/issues/1) There's a PR :smile: --> https://github.com/tahoe-lafs/zfec/pull/4 !

Dependencies

lib	Latest Python 3 support	PyPI: release	PyPI: Py version	PyPI: Uploaded on
gevent	3.7	1.3a1	3.7	recently
gmpy2	3.6	2 2.1.0a1	3.6	recently
pysocks	3.6	1.6.8	3.6	recently
zfec	3.7	1.5.0	3.7	recently
Charm-Crypto	3.6 (from github)	0.43	3.4	2015-08-14
ecdsa	3.6 (from github)	0.13	3.4	2015-02-07
gipc	3.6 (from github)	0.6.0	3.4	2015-07-22
pycrypto	3.4	2.6.1	3.4	2014-06-20

Notes

Some details to watch out for.

charm-crypto

The latest charm-crypto cannot be installed simply with pip as there is an error when setting config values. This can be worked around by cloning the repo and performing the configuration to create a config file and running make, and then pip installing. So not a big deal, but inconvenient.

• [ ] Will look if an issue has already been filed, and if not will file one.

pycrypto

• Latest commit https://github.com/dlitz/pycrypto/commit/7acba5f3a6ff10f1424c309d0d34d2b713233019 on Jun 20, 2014

• 50 opened pull requests (https://github.com/dlitz/pycrypto/pulls)

• 111 opened issues (https://github.com/dlitz/pycrypto/issues)

• [ ] Figure out what's up with the project.

[amiller]

This reminds me that zfec will also be a dependency of honeybadger-go. Maybe the solution in either case will be to give zfec an interface so it can be called from a separate process?

[sbellem]

This reminds me that zfec will also be a dependency of honeybadger-go. Maybe the solution in either case will be to give zfec an interface so it can be called from a separate process?

I'm not sure what's the best approach for Go. I guess that ideally you would want a Go implementation of zfec, but time wise that is probably not ideal.

As for Python I just noticed that there was already a PR for Python 3 support (https://github.com/tahoe-lafs/zfec/pull/4) and it is not so big. So I would prefer helping with getting this PR through, assuming that there's not too much work left to be done :smile: !

[sbellem]

UPDATE: Python 3 only port is under branch https://github.com/sbellem/HoneyBadgerBFT/tree/python3-port

All tests are passing, and the coverage is at 79%.

Things that are left to do (see Porting Python 2 Code to Python 3 for help):

• [x] bring code coverage to 100% or nearby (#40, #48) -- work in PR #58
• [x] Run source code analyzers (e.g. pylint, flake8, etc) and fix errors (#33).
• [x] clean up code changes
• [x] see whether it makes sense to keep Python 2 support -- can be dropped :)
• [x] add python 3 classifiers in setup.py
  • [x] ideally, run experiments/benchmarks with Python 3 version to make sure it still works (#45) will be handled separately

[amiller]

This is fantastic work, thanks for being so systematic and looking into the zfec dependency especially. I appreciate that you set up the dependency link in the meantime to your own fork while also nudging them to merge the pull request!

I would be happy to adopt python3 even without maintaining python2 compatibility for this.

[sbellem]

Thanks to @tpltnt, pyutil now supports Python 3! This is a step forward for the zfec PR: https://github.com/tahoe-lafs/zfec/pull/4#issuecomment-357302645.

[sbellem]

This is a step forward for the zfec PR: tahoe-lafs/zfec#4 (comment).

zfec now supports Python 3.

[sbellem]

Closing as it was handled in initc3/HoneyBadgerBFT-Python#3