-
Notifications
You must be signed in to change notification settings - Fork 690
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop dh-virtualenv #6538
Comments
Here's my demo of this change against securedrop-client: freedomofpress/securedrop-builder@a580cf0 - I think it's significantly clearer exactly what is happening during the install step (the sed step probably needs a comment). The diffoscope report: https://gist.github.com/legoktm/61d28e6f045bbcb10500114b9ee8f1f4 - the useless interpreter hook is removed, and insignificant quoting changes plus one spot VIRTUAL_ENV wasn't updated properly that the new sed command fixes. |
💡 I find the diffoscope report very compelling! The changes, given your explanation in this PR's description, seem very reasonable to me 👍 |
Yeah this seems all around reasonable. Added bonus, if I'm not mistaken we could probably use the same approach for the workstation/launcher/updater RPM package (which would greatly benefit from standardisation) |
RPM by default strips away libraries and that can cause trouble in similar case. Otherwise I also wrote https://github.com/kushaldas/rpm-macros-virtualenv :) |
I just filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030170 about how it's incompatible with bookworm's Python 3.11. It was fixed upstream last month (see spotify/dh-virtualenv#354) and merged by the maintainer very quickly, but no new release nor an update in Debian. It also doesn't appear to be running the standard Debian CI autopkgtests tests that would've flagged this automatically rather than needing human reports. I'll wait a day or two before kicking off the NMU process to fix it again. |
Done, it'll take ~10 days to migrate into bookworm, for now I've proposed just patching it via sed when we install deps: freedomofpress/securedrop-builder@dcbe842 |
The failure at freedomofpress/securedrop-builder#414 has actually been emitting deprecation warnings in bullseye, except dh_virtualenv has been hiding them. Using the demo from #6538 (comment), here's the output you get from building securedrop-client on bullseye without dh_virtualenv:
Unfortunately dh_virtualenv hides those messages so we didn't notice when we switched to bullseye in the first place. On bookworm with dh_virtualenv, the error you get is:
Contrast that with the bookworm output without dh_virtualenv:
|
dh-virtualenv is responsible for creating the virtualenv, installing dependencies from requirements.txt, and then munging the virtualenv to use the path that it will be installed to. There are a number of issues with it however: * largely unmaintained in Debian (missed focal) * incompatible with debhelper compat 12 * cannot use --require-hashes * hides deprecation warnings and error messages It is now getting in the way of Rust packaging since we want to install a wheel into the virtualenv, however it needs to happen before the munging step, which dh-virtualenv doesn't really support. Since we already want to get rid of it, let's just do it now. Fixes #6538.
dh-virtualenv is responsible for creating the virtualenv, installing dependencies from requirements.txt, and then munging the virtualenv to use the path that it will be installed to. There are a number of issues with it however: * largely unmaintained in Debian (missed focal) * incompatible with debhelper compat 12 * cannot use --require-hashes * hides deprecation warnings and error messages It is now getting in the way of Rust packaging since we want to install a wheel into the virtualenv, however it needs to happen before the munging step, which dh-virtualenv doesn't really support. Since we already want to get rid of it, let's just do it now. Fixes #6538.
dh-virtualenv is responsible for creating the virtualenv, installing dependencies from requirements.txt, and then munging the virtualenv to use the path that it will be installed to. There are a number of issues with it however: * largely unmaintained in Debian (missed focal) * incompatible with debhelper compat 12 * cannot use --require-hashes * hides deprecation warnings and error messages It is now getting in the way of Rust packaging since we want to install a wheel into the virtualenv, however it needs to happen before the munging step, which dh-virtualenv doesn't really support. Since we already want to get rid of it, let's just do it now. Fixes #6538.
dh-virtualenv is responsible for creating the virtualenv, installing dependencies from requirements.txt, and then munging the virtualenv to use the path that it will be installed to. There are a number of issues with it however: * largely unmaintained in Debian (missed focal) * incompatible with debhelper compat 12 * cannot use --require-hashes * hides deprecation warnings and error messages It is now getting in the way of Rust packaging since we want to install a wheel into the virtualenv, however it needs to happen before the munging step, which dh-virtualenv doesn't really support. Since we already want to get rid of it, let's just do it now. Fixes #6538.
dh-virtualenv is responsible for creating the virtualenv, installing dependencies from requirements.txt, and then munging the virtualenv to use the path that it will be installed to. There are a number of issues with it however: * largely unmaintained in Debian (missed focal) * incompatible with debhelper compat 12 * cannot use --require-hashes * hides deprecation warnings and error messages It is now getting in the way of Rust packaging since we want to install a wheel into the virtualenv, however it needs to happen before the munging step, which dh-virtualenv doesn't really support. Since we already want to get rid of it, let's just do it now. Fixes #6538.
dh-virtualenv is responsible for creating the virtualenv, installing dependencies from requirements.txt, and then munging the virtualenv to use the path that it will be installed to. There are a number of issues with it however: * largely unmaintained in Debian (missed focal) * incompatible with debhelper compat 12 * cannot use --require-hashes * hides deprecation warnings and error messages It is now getting in the way of Rust packaging since we want to install a wheel into the virtualenv, however it needs to happen before the munging step, which dh-virtualenv doesn't really support. Since we already want to get rid of it, let's just do it now. Fixes #6538.
Description
We currently use
dh-virtualenv
to create a virtualenv that we install our dependencies in. It has some nice features, and some downsides. I believe that we've reached the point that the downsides outweigh the features, which are simple to reimplement ourselves. This is a proposal for all the SDW components too, I just didn't want to file two identical tickets and split discussion.Features
/opt/venvs/...
, installs dependencies and our code./debian/securedrop-app-code
and then moved toopt/venvs
)securedrop-app-code
package install #6230)Downsides
twicethrice already so it stays in testing--require-hashes
: https://github.com/freedomofpress/securedrop-debian-packaging/issues/79Proposal
python3 -m venv ...
pip install ...
I think this will also demystify exactly what is happening at build time since we can see the underlying pip/virtualenv commands.
The text was updated successfully, but these errors were encountered: