RetroSearch Browse

Sun Feb 21 21:53:33 CET 2010 · http://mail.python.org/pipermail/python-dev/2010-February/097851.html

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 <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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100221/be36233c/attachment.html>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2010-February/097851.html below:

[Python-Dev] Proposal for virtualenv functionality in Python