<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Ian Bicking wrote:
<blockquote
cite="mid:b654cd2e1002211043r4c20ac19ib629d42b8159c7dd@mail.gmail.com"
type="cite">On Sun, Feb 21, 2010 at 12:32 PM, Larry Hastings <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:larry@hastings.org">larry@hastings.org</a>></span>
wrote:
<div class="gmail_quote">
<div>* 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.</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:b654cd2e1002211043r4c20ac19ib629d42b8159c7dd@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>* Control global site-packages: people use this all the time
with virtualenv.</div>
<div>*
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.</div>
<div>* 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.</div>
</div>
</blockquote>
<br>
Okey-doke, I defer to your experience.<br>
<br>
Obviously if this is going into Python we can do better than
monkeypatching distutils.<br>
<br>
<blockquote
cite="mid:b654cd2e1002211043r4c20ac19ib629d42b8159c7dd@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* pythonv's purpose in life is to infer your prefix directory and<br>
run "pythonX.X --prefix <prefixdir> [ all args it got ... ]".<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
/larry/
</body>
</html>