[Distutils] pythonv, take two

[Vinay Sajip]

Carl Meyer <carl <at> oddbird.net> writes:

> 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