[Python-Dev] Proposal for virtualenv functionality in Python (original) (raw)

Larry Hastings larry at hastings.org
Sun Feb 21 21:53:33 CET 2010

Ian Bicking wrote:

On Sun, Feb 21, 2010 at 12:32 PM, Larry Hastings <larry at hastings.org_ _<mailto:larry at 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 [ 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20100221/be36233c/attachment.html>

More information about the Python-Dev mailing list