Bundle pyqt with securedrop-client

[sssoleileraaa]

Description

I am curious why we use the system pyqt instead of adding it to our production build requirements. Anyone with the history on this decision?

Background

This bug was not discovered during development of the client because we have a different version of PyQt specified in our dev-requirements.txt file. We would have caught this bug if we were matching PyQt versions between development and prod (I tested by running pip install pyqt5==5.11.3 in dev to see the crash).

Should we update dev-requirements.txt to use the same version of pyqt5 that we use on prod? Also, we may want to add a script or a checkbox in our Test Plan that gets added to PRs to remind us to double-check this.

[kushaldas]

I am curious why we use the system pyqt instead of adding it to our production build requirements. Anyone with the history on this decision?

Because we will have to match the Qt version too with the PyQt version. And building all of Qt for our own usecase in Debian is too much work for maintenance.

Also, building Qt/PyQt properly is still hard.

[sssoleileraaa]

So I think we just need to add a test that will fail when it runs on Qubes to check that the system qt package matches what we have in dev.

[rmol]

A vignette vivifying the viperous vagaries of version variance can be viewed via #825 (comment).

[sssoleileraaa]

Just an update since it's been a while:

I still think this is a good test to have in order to ensure our dev-requirement.txt version matches the system package (right now its 5.11.3 on buster)

[sssoleileraaa]

I renamed this issue to "Bundle pyqt with securedrop-client" because the system version is old and full of bugs.

I am curious why we use the system pyqt instead of adding it to our production build requirements. Anyone with the history on this decision?

Because we will have to match the Qt version too with the PyQt version. And building all of Qt for our own usecase in Debian is too much work for maintenance.

Also, building Qt/PyQt properly is still hard.

Since this issue was opened, we changed our version of PyQt in development to match the version used in prod, but we've learned that we can only get close to the same version of the python-pyqt5 and python-sip rather than exact version (even when we use pyqt5 5.11.3, since the system package is pyqt5 5.11.3+dfsg-1+b3, we see issues on prod but not on dev). Also, there are more bugs in the system version because it is using packages from 2018 so we have to develop workarounds to bugs fixed in newer versions.

I want to discuss the issue of bundling PyQt with securedrop-client once again. We started work on creating our own Qt and PyQt builds (debug versions too), see #1089, but I also want to discuss the possibility of installing the latest version of PyQt in our dh-virtualenv. I think we should continue to work on #1089 because it'll help with debugging upstream issues, but I'm curious why we don't just install a later PyQt version in the prod dh-virtualenv.

[eloquence]

Closing for now due to build issues with pyqt; we've agreed to investigate pyside2 (#1194), which seems a more promising, supported path to bundling Qt bindings with the app.