On Sat, Oct 23, 2010 at 14:33, Ian Bicking <ianb@colorstudy.com> wrote:
> On Sat, Oct 23, 2010 at 4:27 PM, Brett Cannon <brett@python.org> wrote:
>>
>> Is this email meant to simply point out the existence of pythonv, or
>> to start a conversation about whether something should be tweaked in
>> Python so as to make pythonv/virtualenv easier to implement/use?
>
> Both?  I have felt guilty for not following up on what Larry did, so this is
> my other-people-should-think-about-this-too email.
>
>>
>> If it's the latter then let's have the conversation! This was brought
>> up at the PyCon US 2010 language summit and the consensus was that
>> modifying Python to make something like virtualenv or pythonv easier
>> to implement is completely acceptable and something worth doing.
>
> OK, sure!  Mostly it's about changing site.py.

OK, what exactly needs to change?

Well, add a notion of "prefixes", where the system sys.prefix is one item, but the environment location is the "active" sys.prefix.  Then most of the site.py changes can follow logically from that (whatever you do for the one prefix, do for all prefixes).  Then there's a matter of using an environmental variable to add a new prefix (or multiple prefixes -- inheritable virtualenvs, if virtualenv allowed such a thing).  In the pythonv implementation it sets that variable, and site.py deletes that variable (it could be a command-line switch, that's just slightly hard to implement -- but it's not intended as an inheritable attribute of the execution environment like PYTHONPATH).
">

(original) (raw)

On Sat, Oct 23, 2010 at 5:11 PM, Brett Cannon <brett@python.org> wrote:

On Sat, Oct 23, 2010 at 14:33, Ian Bicking <ianb@colorstudy.com> wrote:
\> On Sat, Oct 23, 2010 at 4:27 PM, Brett Cannon <brett@python.org> wrote:
\>>
\>> Is this email meant to simply point out the existence of pythonv, or
\>> to start a conversation about whether something should be tweaked in
\>> Python so as to make pythonv/virtualenv easier to implement/use?
\>
\> Both? I have felt guilty for not following up on what Larry did, so this is
\> my other-people-should-think-about-this-too email.
\>
\>>
\>> If it's the latter then let's have the conversation! This was brought
\>> up at the PyCon US 2010 language summit and the consensus was that
\>> modifying Python to make something like virtualenv or pythonv easier
\>> to implement is completely acceptable and something worth doing.
\>
\> OK, sure! Mostly it's about changing site.py.

OK, what exactly needs to change?

Well, add a notion of "prefixes", where the system sys.prefix is one item, but the environment location is the "active" sys.prefix. Then most of the site.py changes can follow logically from that (whatever you do for the one prefix, do for all prefixes). Then there's a matter of using an environmental variable to add a new prefix (or multiple prefixes -- inheritable virtualenvs, if virtualenv allowed such a thing). In the pythonv implementation it sets that variable, and site.py deletes that variable (it could be a command-line switch, that's just slightly hard to implement -- but it's not intended as an inheritable attribute of the execution environment like PYTHONPATH).



> The pythonv executable is

> itself very simple, just a shim to make #! easier.


But that's in C, though, right? What exactly does it do? It would be
best to make it if the shim can be in Python so that other VMs can
work with it.

#! doesn't work with a Python target, otherwise it would be easy to implement in Python. #! is awful.

--
Ian Bicking | http://blog.ianbicking.org