The recent path discussion reminded me of a project I talked about with Larry Hastings at the last PyCon about virtualenv and what could possibly be included into Python. Larry worked on a prototype that I was supposed to do something with, and then I didn't, which is lame of me but deserves some note: http://bitbucket.org/larry/pythonv/src It satisfies several requirements that I feel virtualenv accomplishes and a lot of other systems do not; but it also has a few useful features virtualenv doesn't have and is much simpler (mostly because it has a compiled component, and changes the system site.py). The features I think are important: * Works with "environments", which is a set of paths and installed components that work together (instead of just ad hoc single path extensions like adding one entry to PYTHONPATH) * Modifies sys.prefix, so all the existing installation tools respect the new environment * Works with #!, which basically means it needs its own per-environment interpreter, as #! is so completely broken that it can't have any real arguments (though it occurs to me that a magic comment could work) * Doesn't use environmental variables (actually it uses them internally, but not in a way that is exposed to developers) -- for instance, hg should not be affected by whatever development you are doing just because it happens to be written in Python Anyway, I think what Larry did with pythonv accomplishes a lot of these things, and probably some more constraints that I've forgotten about. It does have a more complicated/dangerous installation procedure than virtualenv (but if it was part of Python proper that would be okay). -- Ian Bicking | http://blog.ianbicking.org
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? 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. On Sat, Oct 23, 2010 at 12:32, Ian Bicking <ianb@colorstudy.com> wrote:
On Sat, Oct 23, 2010 at 4:27 PM, Brett Cannon <brett@python.org> wrote:
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.
OK, sure! Mostly it's about changing site.py. The pythonv executable is itself very simple, just a shim to make #! easier. For Windows it would have to be different (maybe similar to Setuptools' cmd.exe), but... I think it's possible, and I'd just hope some Windows people would explore what specifically is needed. virtualenv has another feature, which isn't part of pythonv and needn't be part of Python, which is to bootstrap installation tools. -- Ian Bicking | http://blog.ianbicking.org
On Sat, Oct 23, 2010 at 14:33, Ian Bicking <ianb@colorstudy.com> wrote:
OK, what exactly needs to change?
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. -Brett
On Sat, Oct 23, 2010 at 5:11 PM, Brett Cannon <brett@python.org> wrote:
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).
#! doesn't work with a Python target, otherwise it would be easy to implement in Python. #! is awful. -- Ian Bicking | http://blog.ianbicking.org
On Sat, Oct 23, 2010 at 15:16, Ian Bicking <ianb@colorstudy.com> wrote:
OK, so it sounds like site.py would just need a restructuring. That's sounds like just a technical challenge and not a backwards-compatibility one. Am I right?
As in a #! can't target a Python script that has been chmod'ed to be executable?
On Sat, Oct 23, 2010 at 05:12:35PM -0700, Brett Cannon wrote:
It also handles parameters in strange ways. One can write #!/usr/bin/pytnon -O but not #!/usr/bin/env pytnon -O Some operating systems understand that, some ignore -O completely, but most OSes interpret "python -O" as one parameter and emit "/usr/bin/env: python -O: No such file or directory" error. Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
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? 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. On Sat, Oct 23, 2010 at 12:32, Ian Bicking <ianb@colorstudy.com> wrote:
On Sat, Oct 23, 2010 at 4:27 PM, Brett Cannon <brett@python.org> wrote:
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.
OK, sure! Mostly it's about changing site.py. The pythonv executable is itself very simple, just a shim to make #! easier. For Windows it would have to be different (maybe similar to Setuptools' cmd.exe), but... I think it's possible, and I'd just hope some Windows people would explore what specifically is needed. virtualenv has another feature, which isn't part of pythonv and needn't be part of Python, which is to bootstrap installation tools. -- Ian Bicking | http://blog.ianbicking.org
On Sat, Oct 23, 2010 at 14:33, Ian Bicking <ianb@colorstudy.com> wrote:
OK, what exactly needs to change?
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. -Brett
On Sat, Oct 23, 2010 at 5:11 PM, Brett Cannon <brett@python.org> wrote:
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).
#! doesn't work with a Python target, otherwise it would be easy to implement in Python. #! is awful. -- Ian Bicking | http://blog.ianbicking.org
On Sat, Oct 23, 2010 at 15:16, Ian Bicking <ianb@colorstudy.com> wrote:
OK, so it sounds like site.py would just need a restructuring. That's sounds like just a technical challenge and not a backwards-compatibility one. Am I right?
As in a #! can't target a Python script that has been chmod'ed to be executable?
On Sat, Oct 23, 2010 at 05:12:35PM -0700, Brett Cannon wrote:
It also handles parameters in strange ways. One can write #!/usr/bin/pytnon -O but not #!/usr/bin/env pytnon -O Some operating systems understand that, some ignore -O completely, but most OSes interpret "python -O" as one parameter and emit "/usr/bin/env: python -O: No such file or directory" error. Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
participants (4)
-
Brett Cannon -
Ian Bicking -
Oleg Broytman -
Raymond Hettinger