Repository navigation
python 3 port plan #1712
Description
Activity
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
cibranch I havepython "3.6"inallow_failuresand build itself succeeds if python3 part fails. But we all see the failures.Not sure what to do if requirements.txt diverge between python 2 and python 3.
Unlikely
In my
cibranch I havepython "3.6"inallow_failuresand 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,
pybitmessagecould simply print "python3 version not ready yet, use python2" when run under python3.- added a commit that references this issue
on Jan 27, 2021 @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.
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.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.
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.
just as to make sure that PyBitmessage works above Python 3.5 at least.
PyBitmessage currently does not support python3.
- added a commit that references this issue
on Apr 29, 2021 It seems I read here something you didn't write and maybe didn't even mean. Do you agree that if somebody wants to participate in the porting process, he should:
- chose an entity: a structure, a module, a thread or a couple of them (for example objectProcessor works together with addressGenerator)
- cover it by tests
- when the tests pass with python2, edit the code to support python3
Furthermore, it's not related to the python3 porting process but it used to be so - in order to pass a review PR should fit the following criteria:
- comply with PEP8
- have one commit per change with descriptive messages
- do not include unrelated changes
- do not introduce unneeded extra files
The latest merge violates all the points. I'm surprised that it even passed pylint check.
@g1itch Your proposals make sense. I appreciate you giving feedback to the other developers.
Unfortunately for personal reasons I have very little time to code review nowadays. I also didn't have any help from the developer that normally helps me in this process as she had time off for personal reasons too (for about 1.5 months). At the same time however, I'm paying developers to work on the project, and they either need feedback or their code merged, or I pay them to do nothing. The project is in an annoying phase when python2 compatibility is being dropped by more and more distros and dependencies, but python3 code isn't working sufficiently well to have the whole program run.
For these reasons I approved PRs I otherwise wouldn't have. Hopefully, now more python3 code can be worked on, and some tests that require full app can be refactored or created from scratch using mocks. Existing code can be cleaned up. And developers can work without having to wait for each other's PRs to be merged, so development can work in parallel.
I should have more time starting in about 3-4 weeks, around the end of May. Perhaps then we can make the process more strict again.
- pinned this issue
on Jun 22, 2021 Meanwhile the official doc explicitly mentions test coverage and the bad practice of using
sys.version_info: https://docs.python.org/3/howto/pyporting.html#use-feature-detection-instead-of-version-detectionAs for requirements, you can separate them by version using environment markers e.g.
diff --git a/requirements.txt b/requirements.txt index 899753cb..65fafe75 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,5 +1,6 @@ coverage python_prctl;platform_system=="Linux" +PyQt5;python_version>="3.8" psutil pycrypto six
Is there a branch/repo/milestone to follow the python3 port?
@g1itch are you still working on this?
Have you progressed on it?
After revisiting this 9 months later, I think it's safe to say that bitmessage is dying. There are few distros that still package pyqt4, leaving this to be deployable to few. Unless someone decides to take this on, probably best to archive your keys and move your chats elsewhere.
The development is currently paused but should resume in a couple of months. While running from source may be problematic, you can use the binaries (like appimage) until the python3 port is done.
@PeterSurda Is there a link to the AppImage that's published from an official build source, preferably signed?
This is the latest one: https://appimage.bitmessage.org/releases/20230116/ . I understand it's a bit of indirect. Automated signing isn't implemented at the moment.
Reacted by Asherathe@PeterSurda Thanks for following up. Good luck with the python3 migration. I'll check back in at the end of the year :)
Using the principles of continuous delivery, port to python 3 should progress as following:
pybitmessagebinary 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.