How to setup the development environment which is identical to the one core developers are using? #2229

Open
opened 2024-05-17 08:21:36 +02:00 by kashikoibumi · 14 comments
kashikoibumi commented 2024-05-17 08:21:36 +02:00 (Migrated from github.com)

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 :)

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 :)
PeterSurda commented 2024-05-17 12:07:43 +02:00 (Migrated from github.com)

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.

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.
kashikoibumi commented 2024-05-18 09:57:14 +02:00 (Migrated from github.com)

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.

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.
PeterSurda commented 2024-05-18 16:33:42 +02:00 (Migrated from github.com)

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.

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.
PeterSurda commented 2024-05-18 16:36:16 +02:00 (Migrated from github.com)

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.

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.
kashikoibumi commented 2024-05-18 16:45:47 +02:00 (Migrated from github.com)

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?

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? > 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.
PeterSurda commented 2024-05-18 16:51:21 +02:00 (Migrated from github.com)

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

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
kashikoibumi commented 2024-05-18 17:03:48 +02:00 (Migrated from github.com)

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.

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.

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.

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. > 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. 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.
kashikoibumi commented 2024-05-18 17:08:49 +02:00 (Migrated from github.com)

Interesting!

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: #1603

Interesting! > 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: #1603
PeterSurda commented 2024-05-19 05:06:21 +02:00 (Migrated from github.com)

I don't like Ubuntu. It's managed by profit company.

Well, you don't have to use it, it's just going to get more difficult to setup an environment for python2/Qt4.

I have no high-end machine, so VM can not run smoothly. I'm poor enough to be unable to buy new computer.

I understand. But as a result you're going to spend unnecessarily lot of time working around the restrictions.

I don't like docker. I had tried to follow a docker tutorial once several years ago, but failed to understand.

This is unfortunate as with containerisation you can greatly enhance your development performance.

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.

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.

> I don't like Ubuntu. It's managed by profit company. Well, you don't have to use it, it's just going to get more difficult to setup an environment for python2/Qt4. > I have no high-end machine, so VM can not run smoothly. I'm poor enough to be unable to buy new computer. I understand. But as a result you're going to spend unnecessarily lot of time working around the restrictions. > I don't like docker. I had tried to follow a docker tutorial once several years ago, but failed to understand. This is unfortunate as with containerisation you can greatly enhance your development performance. > 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. 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.
kashikoibumi commented 2024-05-19 05:13:39 +02:00 (Migrated from github.com)

debootstrap!!
I completely forgot it!
Thanks, I will try it later :)

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 :) > 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.
kashikoibumi commented 2024-05-19 05:22:43 +02:00 (Migrated from github.com)

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 :)

I have no high-end machine, so VM can not run smoothly. I'm poor enough to be unable to buy new computer.

I understand. But as a result you're going to spend unnecessarily lot of time working around the restrictions.

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 :) > > I have no high-end machine, so VM can not run smoothly. I'm poor enough to be unable to buy new computer. > > I understand. But as a result you're going to spend unnecessarily lot of time working around the restrictions.
kashikoibumi commented 2024-05-21 01:12:19 +02:00 (Migrated from github.com)

The debootstrap method works almost perfectly!

sudo su
apt-get update
apt-get install debootstrap

# If you use Debian instead of Devuan,
# use 'buster' instead of 'beowulf'.
debootstrap beowulf /home/bm

chroot /home/bm
apt-get install python-qt4
apt-get install python-six
apt-get install git

apt-get install locales
# if you use English and Japanese,
# choose: en_US.UTF-8 and ja_JP.UTF-8
dpkg-reconfigure locales
apt-get install fonts-takao  # Japanese font

adduser user
su user
cd
git clone https://github.com/Bitmessage/PyBitmessage.git
cd PyBitmessage
./start.sh

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.

The debootstrap method works almost perfectly! ``` sudo su apt-get update apt-get install debootstrap # If you use Debian instead of Devuan, # use 'buster' instead of 'beowulf'. debootstrap beowulf /home/bm chroot /home/bm apt-get install python-qt4 apt-get install python-six apt-get install git apt-get install locales # if you use English and Japanese, # choose: en_US.UTF-8 and ja_JP.UTF-8 dpkg-reconfigure locales apt-get install fonts-takao # Japanese font adduser user su user cd git clone https://github.com/Bitmessage/PyBitmessage.git cd PyBitmessage ./start.sh ``` 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.
kashikoibumi commented 2024-05-21 01:22:31 +02:00 (Migrated from github.com)

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.

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.
kashikoibumi commented 2024-06-22 16:59:06 +02:00 (Migrated from github.com)

Debian 10 LTS buster will be dropped on June 30th, 2024, which is the last version including Python2 deb package >_<

Debian 10 LTS buster will be dropped on June 30th, 2024, which is the last version including Python2 deb package >_<
This repo is archived. You cannot comment on issues.
No Milestone
No project
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Bitmessage/PyBitmessage-2024-08-21#2229
No description provided.