Carl Meyer
The logical conclusion of that approach, if you want full compatibility with third-party code, is to just copy the entire Python installation to the new location.
We do want that compatibility, don't we? Using a virtual environment should be a no-brainer, as virtualenv currently is (most of the time). Of course, the downside of the copying would be around 50MB per virtualenv on Windows, and much less where symlinking or hardlinking is available. Not ideal, of course, but disk space is cheap ;-)
So three options as I see it:
1) Add sys.virtual_prefix (or perhaps sys.site_prefix would be a better name), and require third-party code to use that (or sysconfig) to find site-packages, if it wants to be virtual-compatible.
But the success of virtualenv is because you can install just about any package in an environment, and packages don't have to do anything to be "virtual compatible".
2) Repoint sys.prefix, and require third-party code to understand some new sys.system_prefix or sys.installed_prefix or equivalent to find the rest of the base Python installation.
I think that the answer is for third party code not to use any prefix directly, but rely on an API such as sysconfig.get_path('purelib'). There's a distutils version of this - distutils.sysconfig.get_python_lib() - but this is brittle as per issue #6087.
3) Attempt the virtualenv approach of trying to fool third-party code into thinking the virtualenv IS a full Python installation, even though it's not.
I think #1 is far preferable to #2, and in the long run preferable to #3 even if it involves some short-term pain. But maybe I'm being too idealistic, and #3 is the pragmatic choice even though it's "wrong."
I'm afraid you may be right, at least until people stop using sys.prefix and sys.exec_prefix directly and call functions instead, which can operate differently in a virtual environment. Regards, Vinay Sajip