With a recent update to
/usr/bin/python, all my virtual environments were broken. I have an easy solution to the problem – delete and re-create them – but that’s not very friendly to people encountering this for the first time.
Since this affects both
venv, I’m posting here rather than opening issues.
Following PEP 394 the
python command on my system was a series of symlinks:
After an update (of the whole OS in my case), this changed to:
I have both
python3.10 available (both before and after), but I assume there are people who only want one version – the latest one that’s sufficiently stable.
When virtual environments (both venv and virtualenv) are created, they use symlinks to the Python they are created with. So after a
python -m venv my_env, I end up with:
which will break after
python3 is updated to
python3.11 – the library in
my_venv/lib/python3.10 won’t be usable.
Looking at this, it would make sense to me that if
sys.executable is a symlink, virtual environment tools would resolve it before pointing to it. But I probably don’t know the whole picture. Are there any downsides to that approach? Is there any discussion I should read up on?
(We briefly looked into how this would affect nested venvs with
--system-site-packages, but that looks messy even now.)
And while I’m here: as a distro maintainer, I’d love to have a way to provide a system-spectftc message for venv/virtualenv activation scripts saying “this Python was uninstalled, here’s the command to bring it back”. Does that sound like a good idea?