Hi, can we have a test folder like "qt/test" as an equivalent to "common/test"? I tried to understand the configure files in "qt" and "common" but they are different. Bash scripts not my thing and very hard to read. I'm scared that I would mess up something. Background: I would like to have a "qt/test/test_qt.py" that only does an "import PyQt5" and doesn't raise an ImportError. This is in preparation of updating ".travis.yml". There where problems "installing" PyQt5 on ppc64le architecture. I'm sure I solved that problem. But to "fix the condition" I would like to add a qt-import-test that would fail if someone else in the future mess up the travis config. Kind Christian
On Thu, 2022-09-29 at 12:44 +0000, c.buhtz@posteo.jp wrote:
can we have a test folder like "qt/test" as an equivalent to "common/test"?
sure, I would add my tests there too (later)
I tried to understand the configure files in "qt" and "common"
If you need help here I can support you (I guess you want to extend the test* make targets in "configure").
I would like to have a "qt/test/test_qt.py" that only does an "import PyQt5" and doesn't raise an ImportError.
What is the purpose of this since it tests the Python environment/setup but not BiT itself
[...] I would like to add a qt-import-test that would fail if someone else in the future mess up the travis config.
I am not sure I understand this right. Is the intention here to "test" that TravisCI has all required packages (qt...) installed?
Am 29.09.2022 20:53 schrieb J. A.:
I guess you want to extend the test* make targets in "configure").
Yes, right.
I would like to have a "qt/test/test_qt.py" that only does an "import PyQt5" and doesn't raise an ImportError.
What is the purpose of this since it tests the Python environment/setup but not BiT itself
It is just a placeholder before we have real Qt test. That test can be removed when the first usual Qt test are implemented. And yes it need to test the environment. I need an "import PyQt5" somewhere because this is problematic in some environments.
I am not sure I understand this right. Is the intention here to "test" that TravisCI has all required packages (qt...) installed?
The Travis setup is very complicated when dealing with PyQt. Took me some hours and support tickets to learn that. Travis runs Ubuntu 20 in a docker container. Each Python version/interpreter runs in a virtual environment. Here comes the point. In a virtual environment all dependencies you use need to be installed via "pip" or "pyhon3 -m pip" (not "apt" and btw not "sudo pip") because only this "local" packages can be seen in a virtual environment. On a AMD64 architecture Ubuntu this is no problem. pip does download and build PyQt5 without any problems. But on ppc64le pip is not able to build PyQt5. The bug is known but I couldn't find a solution. But the Ubuntu package people did some magic and where able to create deb package on a ppc64le architecture. Simply install "sudo apt install python3-pyqt5". But we know this isn't seen in a virtual environment. But there are "special" python interpreter setups for cases where you also want to see the distros own python packages and its own system python interpreter (outside the virtual environment). Ubuntu 20 use Python 3.8. You don't have to tell travis "3.8" but "3.8_with_system_site_packages". And then I had to learn how to hack that into a travis config file. https://github.com/buhtzz/backintime/blob/098aab86098e754270bd3735ab8b3e7775... This travis config do run Python 3.6, 3.9., 3.10 on AMD64 by default and extra (see ":jobs :include" section) one run on a ppc64le architecture with the Ubuntus own Python 3.8. This works. :D
On Thu, 2022-09-29 at 21:16 +0000, c.buhtz@posteo.jp wrote:
But on ppc64le pip is not able to build PyQt5. The bug is known but I couldn't find a solution. But the Ubuntu package people did some magic and where able to create deb package on a ppc64le architecture. Simply install "sudo apt install python3-pyqt5". But we know this isn't seen in a virtual environment.
What a pity, ppc64le was my personal playground, I had a IBM Power9 server at hand until a recently but gave it away. If I had known that... ;-)
But there are "special" python interpreter setups for cases where you also want to see the distros own python packages and its own system python interpreter (outside the virtual environment). Ubuntu 20 use Python 3.8. You don't have to tell travis "3.8" but "3.8_with_system_site_packages". And then I had to learn how to hack that into a travis config file.
https://github.com/buhtzz/backintime/blob/098aab86098e754270bd3735ab8b3e7775...
This travis config do run Python 3.6, 3.9., 3.10 on AMD64 by default and extra (see ":jobs :include" section) one run on a ppc64le architecture with the Ubuntus own Python 3.8. This works. :D
Very good work, Travis is far from being easy to set up!
participants (2)
-
c.buhtz＠posteo.jp -
J. A.