It’s possible to make virtual environments portable if you place a bunch of restrictions on how they’re deployed, such as:
- always using a peer installation of
python-build-standaloneas a runtime layer (or some other runtime that’s decoupled from system Python installations) - disallowing direct wrapper script execution without activating the venv first
- disallowing both direct wrapper script execution and venv activation (requiring the use of module execution instead)
- ensuring (or at least assuming) there aren’t any absolute paths in data files or symlinks
- ensuring any compiled Python files generated in the old location are destroyed and recreated in the new location
conda-pack aims to do that for conda environments. My own venvstacks work project imposes these kinds of limitations to ensure environments can be successfully deployed with a few postinstallation tweaks rather than a full reinstall on the target system.
Having to regenerate pyvenv.cfg in the post-install is mildly irritating, but it’s far from being the trickiest problem in making redeployment to a different location work. So while we could make the startup calculations in CPython even more complicated than they already are, I don’t think it solves enough of the venv portability problem to be worth proposing as a standalone change.