python 3 port plan

[PeterSurda]

Using the principles of continuous delivery, port to python 3 should progress as following:

• the first PR will add allow travis to run python3 while successfully doing nothing. The pybitmessage binary will check if it's running python 3 and if yes, exit with return code 0. Unit tests will be decorated to skip all tests when using python 3. This should allow travis to succeed in python 3. Not sure what to do if requirements.txt diverge between python 2 and python 3.
• gradually tests will be updated to allow running in python 3
• maybe new tests will be written to cater for areas that currently don't have tests to facilitate gradual porting
• once everything is working correctly in python 3, as well as binary builds for the main platforms, python 2 support will be dropped

[g1itch]

the first PR will add allow travis to run python3 while successfully doing nothing. The pybitmessage binary will check if it's running python 3 and if yes, exit with return code 0. Unit tests will be decorated to skip all tests when using python 3. This should allow travis to succeed in python 3.

In my ci branch I have python "3.6" in allow_failures and build itself succeeds if python3 part fails. But we all see the failures.

[g1itch]

Not sure what to do if requirements.txt diverge between python 2 and python 3.

Unlikely

[PeterSurda]

In my ci branch I have python "3.6" in allow_failures and build itself succeeds if python3 part fails. But we all see the failures.

This is interesting, unfortunately it doesn't help me here. I need something that allows a gradual compatibility with python 3 with as little human intervention as possible. If all the errors are just ignored, then a PR reviewer needs more time to figure out what's working and what not by looking at the detailed output. The creator of the PR also needs to spend more time evaluating whether he still needs to continue working or wait for a review. Whereas in my proposal, a failure means the PR is rejected and the PR creator has immediate feedback that the isn't finished, and a success means it's ready for a review. This way, PR after PR, python 3 support will be implemented.

I already tried several approaches for getting python 3 support intergrated but none produced a PR that can be merged. One of the developers produced a branch which has most of the functionality as well as most unit tests working (or at least it looks like it's working), but they don't have the proper quality and aren't chunked nicely for PRs. My proposal allows this to happen (refactor or write from scratch, depending on which makes more sense).

Then there are other minor issues, like travis2bash not understanding the full travis syntax, the non-developers not having proper feedback. In my proposal, pybitmessage could simply print "python3 version not ready yet, use python2" when run under python3.

@g1itch I don't have python2! It is not supported in any new OS. Not even in Debian 11!

I need a Debian 10 virtual machine with Gnome Boxes to run PyBitmessage. Unfortunately.

[g1itch]

@g1itch I don't have python2! It is not supported in any new OS. Not even in Debian 11!

I need a Debian 10 virtual machine with Gnome Boxes to run PyBitmessage. Unfortunately.

Well, for me Ubuntu Focal is recent enough distro and it has python2. Proper flatpack packaging will probably be enough to run current PyBitmessage code on Linux distros with no python2, though I would prefer merging qt5 code first.

[g1itch]

Then there are other minor issues, like travis2bash not understanding the full travis syntax, the non-developers not having proper feedback.

It seems that python: - "3.6" is OK for your buildbot tasks - it's simply ignored: buildbot/travis_focal succeed.

[PeterSurda]

That particular feature is supported. However the VMs don't have python 3.6 so the tests can't run. I'll add python 3.6 into the VMs and then rerun your tests, but it may take a couple of days.

[g1itch]

I'll add python 3.6 into the VMs and then rerun your tests, but it may take a couple of days.

There is no rush. If you take a close look into python 2.7 job of the PR you will see that it's not fully correct. Now I'm discovering some strange behavior of test-mode.