create prod-like dev env

[sssoleileraaa]

Description

Fixes issues where the gui looks different between prod and dev by supporting a dev env that uses system site-packages that you have to install ahead of time (see https://github.com/freedomofpress/securedrop-debian-packaging/blob/main/securedrop-client/debian/control).

Test Plan

0. install these packages on your debian machine (this can be a vm in qubes or native install): https://github.com/freedomofpress/securedrop-debian-packaging/blob/main/securedrop-client/debian/control
1. make venv-debian && source .venv-debian/bin/activate
2. run the client (./run.sh) against a dev server

• Confirm you can see Reply box styled incorrectly and partially enabled during deletion #1286

Checklist

If these changes modify code paths involving cryptography, the opening of files in VMs or network (via the RPC service) traffic, Qubes testing in the staging environment is required. For fine tuning of the graphical user interface, testing in any environment in Qubes is required. Please check as applicable:

• I have tested these changes in the appropriate Qubes environment
• I do not have an appropriate Qubes OS workstation set up (the reviewer will need to test these changes)
• These changes should not need testing in Qubes

If these changes add or remove files other than client code, the AppArmor profile may need to be updated. Please check as applicable:

• I have updated the AppArmor profile
• No update to the AppArmor profile is required for these changes
• I don't know and would appreciate guidance

If these changes modify the database schema, you should include a database migration. Please check as applicable:

• I have written a migration and upgraded a test database based on main and confirmed that the migration applies cleanly
• I have written a migration but have not upgraded a test database based on main and would like the reviewer to do so
• I need help writing a database migration
• No database schema changes are needed

[sssoleileraaa]

just rebased onto main and added babel to the new dev requirements for debian and then ran make requirements here: 26188ee

[sssoleileraaa]

I'm seeing an issue with make test freezing when using the new virtual environment. It seems to be a test runner issue because tests pass when you run each test file individually, e.g. TESTS=tests/gui/test_widgets.py make test, but not when you run make test

[conorsch]

Started review, and appended a commit tweaking the venv creation. Using that commit, I could not reproduce the make test hang that you reported, @creviera. Mind trying again with the rebased version here?

[conorsch]

@creviera These changes work well enough for me. As I mentioned in #1286, I need a tor connection (for the latency) to reproduce that particular issue, but otherwise the changes here look great to me. My major question at this point is: what's the value of supporting the old-school, non-system-packages "venv" at all? In other words, shouldn't this new approach to reusing the Debian system packages be the default? I'd expect that the non-debian venv would be useful to folks developing on e.g. macos, but I haven't actuall tested that. Thoughts?

[conorsch]

I pared back my commit to add only comments, since @creviera rightly pointed out that the manually source actions weren't necessary. This is working well on my machine, which is a Qubes AppVM based on Debian 10 buster. I've not tested on a bare metal install of Debian 10, since I just upgraded my bare metal installation to 11 as part of freedomofpress/securedrop-dev-docs#9. @creviera did note that on her bare metal install, the make test hangs—but neither she nor I can reproduce in a Debian AppVM. This is definitely enough of an improvement that I'm comfortable merging as-is, without any further changes to e.g. CI. Will approve and leave merge to you, @creviera, assuming you agree. =)

[conorsch]

Works well enough for me! Will be performing a lot of repro in the future, will follow up with any required changes as they present themselves.

[sssoleileraaa]

@creviera These changes work well enough for me. As I mentioned in #1286, I need a tor connection (for the latency) to reproduce that particular issue, but otherwise the changes here look great to me. My major question at this point is: what's the value of supporting the old-school, non-system-packages "venv" at all?

conor and i discussed in person and will leave both .venv and .venv-debian since using system site packages can cause some issues with pytest freezing up. until that's for sure fixed, it makes sense to support both.

[sssoleileraaa]

thanks, conor, for the review and troubleshooting (and for leaving the fun button pushing for me at the end)