(original) (raw)
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/