You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes python updates break existing virtualenvs, and you have to copy a new python in or rebuild them to keep things working. I think this really breaks dh-virtualenv as a way of distributing things that don't have a regular release pipeline.
The most recent example of this is 2.6.8 and 2.7.3 which cause import random to fail with "cannot import name urandom" when the package was built with and earlier python. Before that I saw it happen with the MAXREPEAT constant.
I can't think of a good solution for this.
We can't symlink the python binary itself without breaking the virtualenv machinery.
We could possibly use dpkg triggers to automatically update the virtualenv when the system python changes. A bit risky.
Perhaps the cleanest option is to break any symlinks in the virtualenv's stdlib. Replace them with a full copy. This is what virtualenv does on platforms that don't support symlink (unfortunately it's not exposed as a command line option). However that's only a subset of the stdlib, so not enough. We'd have to copy the entire stdlib. Which is lame.
At the very least we could just note in the docs that this can happen.
The text was updated successfully, but these errors were encountered:
Yeah, the underlying python changing is an annoying problem that affects virtualenvs (not just dh-virtualenv). However, it is not that common, though it has happened in the past and probably will happen again.
My opinion is to mention this in someway in docs and instruct people for rebuilding their packages. Rebuilding makes sense anyway, if your python changes underneath, you probably want to verify things still work.
As this is out of scope for dh-virtualenv to handle, I'll close this bug. If you come up with a solution, feel free to open this or (even better) offer something as a form of pull request!
Sometimes python updates break existing virtualenvs, and you have to copy a new python in or rebuild them to keep things working. I think this really breaks dh-virtualenv as a way of distributing things that don't have a regular release pipeline.
The most recent example of this is 2.6.8 and 2.7.3 which cause import random to fail with "cannot import name urandom" when the package was built with and earlier python. Before that I saw it happen with the MAXREPEAT constant.
I can't think of a good solution for this.
We can't symlink the python binary itself without breaking the virtualenv machinery.
We could possibly use dpkg triggers to automatically update the virtualenv when the system python changes. A bit risky.
Perhaps the cleanest option is to break any symlinks in the virtualenv's stdlib. Replace them with a full copy. This is what virtualenv does on platforms that don't support symlink (unfortunately it's not exposed as a command line option). However that's only a subset of the stdlib, so not enough. We'd have to copy the entire stdlib. Which is lame.
At the very least we could just note in the docs that this can happen.
The text was updated successfully, but these errors were encountered: