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:
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't seem like a big issue. 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't understand why this is needed, as current virtualenv doesn't do it and I haven'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? I'll dive into this approach and see what I can achieve. I'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'm almost wondering if a new "virtual" install scheme would be a better approach? Carl Sent from my Android phone ----- Reply message ----- From: "Vinay Sajip" <vinay_sa...@yahoo.co.uk> Date: Wed, Mar 16, 2011 6:13 pm Subject: [Distutils] reservations about pythonv To: <Distutils-Sig@Python.Org> Barry Warsaw <barry <at> python.org> writes: > Here at the sprints we talked about several possible options, the details of > which of course will have to be hashed out. There will also be cross platform > considerations. I think on *nix at least, it would be nice if a symlink and > configuration file were enough to trigger the virtualenv behavior. I feel that this approach definitely has potential to be the most useful and practical. There's no reason for a separate executable if Python itself incorporates the virtual environment functionality, which is mostly about setting paths and environment variables. > For example, if I have a local 'python' symlinked to the real executable, with > a pythonv.conf file next to it, the virtual environment would be enabled. The > real Python binary would adjust its behavior in that case to know where the > standard library was, but also use the locally installed packages. Anyway, > that's how I'd *like* it to work on *nix, but it may have to work differently > on Windows, and it may have to work differently if environment variables have > to be set. Even if on Windows you have to copy rather than symlink, that could just be the main Python executable, which is not prohibitively large since the core of Python is in pythonX.Y.dll. Regards, Vinay Sajip _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
