When I first tried to learn Python last year, the frustration of being a first-timer dealing with the Python 2 vs. Python 3 split very nearly turned me off of the language altogether. While I loved the language itself from first sight, Virtualenv was the tool that finally made Python a joy to <i>use</i>, rather than just a joy to write. This is a very good move.<p>Here's the link to PEP 405:<p><a href="http://www.python.org/dev/peps/pep-0405/" rel="nofollow">http://www.python.org/dev/peps/pep-0405/</a>
Awesome! I'm hard pressed to think of a third party tool that makes more sense for core-inclusion than virtualenv. Hoping the virtualenvwrapper stuff will also be included (or at least similar commands will be)
Does anybody else think that the necessity of virtual environments for programming languages and virtual machines for applications is a sign of failure in package management and sandboxing in modern OSes?
That's good news. Last I looked at virtualenv, though, it could have used more oomph. At the time (last Fall), I was jumping back and forth between Python virtualenv environments and Ruby rvms. RVM was a bit more of a pleasure to use. I hope the virtualenv developers have closed the usability/feature gap since then.
I only skimmed PEP 405, but did anybody get a sense for how this would work with regard to managing different versions of Python per virtualenv? It seems like a tool to do that necessarily has to be higher in the stack than the Python interpreter.