How to setup the development environment which is identical to the one core developers are using? #2229
Labels
No Label
bug
build
dependencies
developers
documentation
duplicate
enhancement
formatting
invalid
legal
mobile
obsolete
packaging
performance
protocol
question
refactoring
regression
security
test
translation
usability
wontfix
No Milestone
No project
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Bitmessage/PyBitmessage-2024-11-28#2229
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
How to setup the development environment which is identical to the one core developers are using?
That must be a good old Python 2.7 + PyQt4 environment.
Usual Linux distributions already dropped them since now is the era of Python 3 + PyQt6.
Although it is far from perfect, I already managed to run PyBitmessage on Python3 + PyQt6, but I found it is not sufficient to be merged to the official repository, anyway.
So I changed the strategy to issue pull requests that seem to be easily accepted to the current PyBitmessage for Python 2.7 + PyQt4.
But there is no easy way to setup a development environment.
I already found and installed PyPy, which is still support Python 2.7.
But I wonder the core developers are using PyPy or not?
PyQt4 may be exist to be installed by pip.
But that can be installed really?
Theoretically, anything can be installed by compiling from the source code, but is it the way the core developers are doing?
Another way, Debian GNU/Linux oldoldoldoldoldstable version is still support Python 2.7 + PyQt4, so I could managed to run PyBitmessage on that environment.
But I wonder the core developers are using such oldoldoldoldoldstable version of a Linux?
Please give me some hints :)
The easiest option is to use codespaces directly in GitHub. It won't work for GUIs (Qt, kivy) but for everything else it should be ok. If you want to run it locally, you can look at the
Dockerfile
that's inside the.devcontainer
directory.Tests can be run with the tox test plugin (which is automatically installed if you use the devcontainer), but due to some strange vscode-server restrictions you first have to open the
tox.ini
file, and then the individual test options will appear under the test menu.It is a major risk if you cannot develop a software without tools from Microsoft.
And, cloud computing is hard for me since I am totally behind away from clearnet using Tor.
Of course you can develop PyBitmessage without tools from Microsoft (except for building windows binaries which do require some Microsoft libraries, even though they are built with wine). I for example develop with vim, but I don't run the tests or builds locally anymore, I let buildbot do it. I use codespaces for pair programming.
If you want to run the PyQt4 version locally while developing, you can base your environment on Ubuntu 18.04, either as a VM or as a container. I for example use it in docker with xpra frontend.
One of the problems with the Qt frontend is that we don't have automated tests for it, so you have to test it locally, for now. There were some attempts but I don't think they were finished.
I don't know GUI world well, but if you know some GUI toolkits that have automatic test facilities, please let me know.
In particularly, does kivy have them?
For kivy, we use telenium. This is what it then looks like: https://artifacts.bitmessage.at/kivy/25018/test.webm
For Qt, this is the PR I was referring to: https://github.com/Bitmessage/PyBitmessage/pull/1603
I don't like Ubuntu.
It's managed by profit company.
I have no high-end machine, so VM can not run smoothly.
I'm poor enough to be unable to buy new computer.
I don't like docker.
I had tried to follow a docker tutorial once several years ago, but failed to understand.
BTW, now I'm trying to build good old Qt4 from source code on my new stable Debian derived Linux.
It is thorned road, so I don't know I can finish or not.
Interesting!
Well, you don't have to use it, it's just going to get more difficult to setup an environment for python2/Qt4.
I understand. But as a result you're going to spend unnecessarily lot of time working around the restrictions.
This is unfortunate as with containerisation you can greatly enhance your development performance.
It should work on an older Debian as from the point of view of the build tooling we use, it's basically the same as Ubuntu.
If you don't like containers, maybe then a simple chroot, using debootstrap, should work, assuming you are also not super low on disk space.
debootstrap!!
I completely forgot it!
Thanks, I will try it later :)
My life is totally killing time.
My true purpose is disabled from the beginning,
so alternatively I was forced to choose playing logical games all over my life.
It's fun, anyway.
I love slow computers :)
The debootstrap method works almost perfectly!
PyBitmessage powered by Python 2.7 + PyQt4 launched successfully!
There are troubles with sounds, but they may be acceptable now.
But, beowulf (buster) is oldoldstable, so when Devuan (Debian) released next major version, it will be dropped, and this bootstrap method will be unable.
I have managed to build Qt4 by two days long surgery.
Next, I tried to build PyQt4 with PyPy-Python 2.7.
But, sipconfig module is requred and it couldn't build yet.
To build it, it seems that some modification of C++ code may be required, so I stucked and gave up finally.
Then, I tried debootstrap method, and almost perfectly succeeded in ten minutes.
Debian 10 LTS buster will be dropped on June 30th, 2024, which is the last version including Python2 deb package >_<