Ian Bicking wrote:

On Sun, Feb 21, 2010 at 12:32 PM, Larry Hastings <larry@hastings.org> wrote:

* Override sys.prefix: allow you to put the binary in someplace other than, say, ~/env/bin/python and still support an environment in ~/env/. Also the use case of looking for libraries in a location based on the interpreter name (not the containing directory), like supporting /usr/bin/python2.7 and /usr/bin/python2.7-dbg.

I'm new to this: why would you want to change sys.prefix in the first place? Its documentation implies that it's where Python itself is installed. I see two uses in the standard library (trace and gettext) and they both look like they'd get confused if sys.prefix pointed at a virtualized directory.

* Control global site-packages: people use this all the time with virtualenv.

* Other locations: well, since Ubuntu/Debian are using dist-packages and whatnot, to get *full* isolation you might want to avoid this. This is really handy when testing setup instructions.

* Control installations: right now distutils only really looks in /usr/lib/pythonX.Y/distutils/distutils.cfg for settings. virtualenv monkeypatches distutils to look in <sys.prefix>/lib/pythonX.Y/distutils/distutils.cfg in addition, and several people use this feature to control virtualenv-local installation.

Okey-doke, I defer to your experience.

Obviously if this is going into Python we can do better than monkeypatching distutils.

* pythonv's purpose in life is to infer your prefix directory and
run "pythonX.X --prefix <prefixdir> [ all args it got ... ]".

I don't see any reason to call the other Python binary, it might as well just act like it was changed. sys.executable *must* point to the originally called interpreter anyway.

If by this you mean pythonv should load the Python shared library / DLL directly, that would make it impossible to stack environments. Which I'm still angling for.

/larry/