This alternative approach (with a symlink and config file) sounds pretty good to me as well after our discussion at the sprints. The downsides I see:<br><br>1. Cross-platform inconsistency. Windows virtualenvs would be isolated from system python binary upgrades, *nix would not (some, like Brandon, consider this isolation a feature, so maybe *nix should allow that option too?) On the whole this doesn&#39;t seem like a big issue.<br><br>2. There would be no way to set LD_LIBRARY_PATH to include the virtualenv prior to execution of python. To be honest, I don&#39;t understand why this is needed, as current virtualenv doesn&#39;t do it and I haven&#39;t seen it break anything (compiled modules work fine in a venv). But people with more experience seemed to think it was needed at our open space discussion last Saturday. Perhaps someone can clarify what specifically breaks without this?<br><br>I&#39;ll dive into this approach and see what I can achieve.<br><br>I&#39;d also appreciate feedback from Tarek or others familiar with the new sysconfig module about my changes there. Something along those lines will I think be needed with either approach, but I&#39;m almost wondering if a new &quot;virtual&quot; install scheme would be a better approach?<br><br>Carl<br><br>Sent from my Android phone<br><br>----- Reply message -----<br>From: &quot;Vinay Sajip&quot; &lt;vinay_sajip@yahoo.co.uk&gt;<br>Date: Wed, Mar 16, 2011 6:13 pm<br>Subject: [Distutils] reservations about pythonv<br>To: &lt;Distutils-Sig@Python.Org&gt;<br><br>Barry Warsaw &lt;barry &lt;at&gt; python.org&gt; writes:<br> <br>&gt; Here at the sprints we talked about several possible options, the details of<br>&gt; which of course will have to be hashed out. &nbsp;There will also be cross platform<br>&gt; considerations. &nbsp;I think on *nix at least, it would be nice if a symlink and<br>&gt; configuration file were enough to trigger the virtualenv behavior.<br><br>I feel that this approach definitely has potential to be the most useful and<br>practical. There&#39;s no reason for a separate executable if Python itself<br>incorporates the virtual environment functionality, which is mostly about<br>setting paths and environment variables.<br><br>&gt; For example, if I have a local &#39;python&#39; symlinked to the real executable, with<br>&gt; a pythonv.conf file next to it, the virtual environment would be enabled. &nbsp;The<br>&gt; real Python binary would adjust its behavior in that case to know where the<br>&gt; standard library was, but also use the locally installed packages. &nbsp;Anyway,<br>&gt; that&#39;s how I&#39;d *like* it to work on *nix, but it may have to work differently<br>&gt; on Windows, and it may have to work differently if environment variables have<br>&gt; to be set.<br><br>Even if on Windows you have to copy rather than symlink, that could just be the<br>main Python executable, which is not prohibitively large since the core of<br>Python is in pythonX.Y.dll.<br><br>Regards,<br><br>Vinay Sajip<br><br>_______________________________________________<br>Distutils-SIG maillist &nbsp;- &nbsp;Distutils-SIG@python.org<br><a href="http://mail.python.org/mailman/listinfo/distutils-sig">http://mail.python.org/mailman/listinfo/distutils-sig</a><br><br><br><br>