venv-update doesn't invalidate its own virtualenvs after python upgrade

[chriskuehl]

I upgraded my system from Debian jessie to stretch. I expected to run make venv and have venv-update notice the new Python version, invalidate my virtualenv, and create a new one. Instead it failed because the venv in ~/.cache/venv-update is no longer valid.

ckuehl@supernova:~/ocf-proj/ocfweb$ make venv
python ./vendor/venv-update venv= venv -ppython3 install= -r requirements.txt -r requirements-dev.txt
> virtualenv venv -ppython3
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ImportError: No module named 'encodings'

Something went wrong! Sending 'venv' back in time, so make knows it's invalid.
Makefile:48: recipe for target 'venv' failed
make: *** [venv] Error 250

If I rm -rf ~/.cache/venv-update, then it does what I expect.

[chriskuehl]

I also had to manually get rid of all of my wheels because they linked against libraries I don't have anymore. Not sure if there's much we can do about that? :(

[asottile]

yeah I don't think there's much that can be done about the wheels. As for the scratch venvs, I think we could add a bit of logic here to ensure the virtualenv is functional:

venv-update/venv_update.py

Line 196 in e9048bd

if not exists(scratch.python):

Maybe even running virtualenv --help or something with that python?

[bukzor]

I'd support a patch to try: the run(virtualenv), then upon exception do a double-check of the stage1 virtualenv. What do we do when the check fails? Simplest is to throw an error with the best explanation that we can. Riskier is to try to auto-fix it and try again.