Support debian packaging #49
Conversation
| @@ -9,10 +9,10 @@ python_version = "3.5" | |||
| [packages] | |||
| SQLALchemy = "*" | |||
| alembic = "*" | |||
| securedrop-sdk = {git = "https://github.com/freedomofpress/securedrop-sdk.git"} | |||
| securedrop-sdk = "*" | |||
There was a problem hiding this comment.
ah right, so the workflow from now when we make a change on the sdk side that we need in the journalist GUI will be us making a new release of the securedrop-sdk and updating on PyPI, i'll do this since we need a release after this change was made: freedomofpress/securedrop-sdk#21
There was a problem hiding this comment.
@redshiftzero Yup, I did a 0.0.1 release so that we can test this packaging story. I think we should do a 0.0.2 release as that will allow us to experiment more as far as the version number goes.
| @@ -51,16 +72,6 @@ | |||
| "index": "pypi", | |||
| "version": "==2.3.2" | |||
| }, | |||
| "pyqt5": { | |||
There was a problem hiding this comment.
thought: instead of removing pyqt5 entirely we should probably move pyqt5 to the development requirements of the Pipfile, since we still want to make sure it's installed in dev/ci/test but not prod/build
There was a problem hiding this comment.
This still can create false positive as dev/ci will be different that production. We should use the same system provided package everywhere.
There was a problem hiding this comment.
Using a pipfile dev dependency enables e.g. macOS developers. If the only way to run the dev env is to use a Debian-based OS, that's going to be a problem. Probably worth accepting a small bit of divergence in order to accommodate dev workflows here.
There was a problem hiding this comment.
yeah, i mean, i'm open to other suggestions here but the only other real option (other than use debian, ha) is to instruct developers on macOS to install qt5 separately in the dev env
There was a problem hiding this comment.
dumb question here -- can we use docker containers and VNC ? if we use system level PyQt versions arent we going to have mismatch between different developers? or is pyqt so rock stable that this shouldn't be a problem? (i swear im not trolling here!)
There was a problem hiding this comment.
Good point @msheiny, with system packages, it's not just "Debian-based OS" that'd be the requirement, but specifically Debian Stretch. Unless you're running Qubes, that's a lot to ask from contributors looking to write a bit of Python code.
The container/VNC strategy is interesting, but given the outstanding deadlines we're working with—particularly the upcoming audit—I suggest we preserve the pyqt dependency in the pipfile via dev dependencies as @redshiftzero suggests.
There was a problem hiding this comment.
I just pushed a commit which adds PyQt5 to the dev dependencies.
There was a problem hiding this comment.
+1 on all this...WRT PyQT stability issues... I'd say it's "mostly" rock solid, except when it isn't. You can draw your own conclusions. ;-)
Uh ok so maybe I'm missing something, but don't we have the sha256 hashes of the package in the lockfile? And also aren't we using |
PyQt directly releases binary wheels to PyPI. We don't know how it is built. Building PyQt dependencies from source (we have to get source from the official website as they are missing in PyPI) is a lot of extra work to maintain. It is much easier to use system provided PyQt5. |
|
Right got it. Totally makes sense. |
|
I see the tests have failed. :-/ |
To make that test pass, we will have to do a new release of |
|
Also we should down the |
| chardet==3.0.4 --hash=sha256:84ab92ed1c4d4f16916e05906b6b75a6c0fb5db821cc65e70cbd64a3e2a5eaae --hash=sha256:fc323ffcaeaed0e0a02bf4d117757b98aed530d9ed4531e3e15460124c106691 | ||
| alembic==1.0.1 --hash=sha256:0fe570f23dc48fb1bbda6f6a396f1c0c28d7045c0ad14018c104a511e6c1fe8a | ||
| sqlalchemy==1.2.12 --hash=sha256:c5951d9ef1d5404ed04bae5a16b60a0779087378928f997a294d1229c6ca4d3e | ||
| securedrop-sdk==0.0.1 --hash=sha256:82373118c49a141881332575c9ac1618973390a7d5c32ed29b3d64cb1f0d91e8 |
There was a problem hiding this comment.
note for other maintainers: these are the build requirements from the first attempt building the securedrop-client package. For the next package build we will need to refresh these build requirements (to pull in securedrop-sdk==0.0.2)
Adds wheel hashes for both Stretch and Buster
Adds optional client side uuid selection for replies
This removes PyQt from management via pipenv, and adds instructions to install system-managed PyQt packages instead. @kushaldas can explain further, but this has to do with our desire to use only packages we can identify by checksum.
This also adds certifi, which I needed to add in order to get the packaged software to run after installation.
The other additions to
Pipfile.lockare transitive fromsecuredrop-sdkThis PR also adds
requirements-build.txt, per @kushaldas 's recommendation: