A new script which creates Python 3.3 venvs with Distribute and pip installed in them

Python 3.3 includes a script, pyvenv, which is used to create virtual environments. However, Distribute and pip are not installed in such environments - because, though they are popular, they are third-party packages - not part of Python. The Python 3.3 venv machinery allows customisation of virtual environments fairly readily. To demonstrate how to do this, and to provide at the same time a script which might be useful to people, I've created a script, pyvenvex.py, at https://gist.github.com/4673395 which extends the pyvenv script to not only create virtual environments, but to also install Distribute and pip into them. The script needs Python 3.3, and one way to use it is: 1. Download the script to a directory in your path, and (on Posix platforms) make it executable. 2. Add a shebang line at the top of your script, pointing to your Python 3.3 interpreter (Posix, and also Windows if you have the PEP 397 launcher which is part of Python 3.3 on Windows). 3. Run the pyvenvex script to create your virtual environments, in place of pyvenv, when you want Distribute and pip to be installed for you (this is how virtualenv sets up environments it creates). You can run the script with -h to see the command line options available, which are a superset of the pyvenv script. Regards, Vinay Sajip

On Wed, Jan 30, 2013 at 9:09 PM, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
Python 3.3 includes a script, pyvenv, which is used to create virtual environments. However, Distribute and pip are not installed in such environments - because, though they are popular, they are third-party packages - not part of Python. The Python 3.3 venv machinery allows customisation of virtual environments fairly readily. To demonstrate how to do this, and to provide at the same time a script which might be useful to people, I've created a script, pyvenvex.py, at https://gist.github.com/4673395 which extends the pyvenv script to not only create virtual environments, but to also install Distribute and pip into them.
Excellent and one step closer to sane package management .... I wonder if you could not source instead the code that is directly in the virtualenv.py scripts? it also includes the packed distribute and pip .... Meaning that would allow the installation entirely offline (with the --never-download venv flag) And btw, why pip is not part of the standard Python? This is nowadays officially recommended on Pypi as the tool to use to install package.... Per http://pypi.python.org/pypi "Get Packages: To use a package from this index either "pip install package" (get pip) or download, unpack and "python setup.py install" it." This does not make sense to me: I know about some of the controversies .... but this is rather inconsistent to recommend using a tool and not supporting it directly. -- Philippe Ombredanne +1 650 799 0949 | pombredanne@nexB.com DejaCode Enterprise at http://www.dejacode.com nexB Inc. at http://www.nexb.com

On 2013-01-31 09:05:17 +0000, Philippe Ombredanne said:
On Wed, Jan 30, 2013 at 9:09 PM, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
Python 3.3 includes a script, pyvenv, which is used to create virtual environments. However, Distribute and pip are not installed in such environments - because, though they are popular, they are third-party packages - not part of Python. The Python 3.3 venv machinery allows customisation of virtual environments fairly readily. To demonstrate how to do this, and to provide at the same time a script which might be useful to people, I've created a script, pyvenvex.py, at https://gist.github.com/4673395 which extends the pyvenv script to not only create virtual environments, but to also install Distribute and pip into them.
Excellent and one step closer to sane package management .... I wonder if you could not source instead the code that is directly in the virtualenv.py scripts? it also includes the packed distribute and pip .... Meaning that would allow the installation entirely offline (with the --never-download venv flag)
And btw, why pip is not part of the standard Python? This is nowadays officially recommended on Pypi as the tool to use to install package.... Per http://pypi.python.org/pypi "Get Packages: To use a package from this index either "pip install package" (get pip) or download, unpack and "python setup.py install" it."
This does not make sense to me: I know about some of the controversies .... but this is rather inconsistent to recommend using a tool and not supporting it directly.
I think the short answer, as always, is: getting pip into the stdlib would require a tremendous amount of work that some would have to want to do[1] before it could happen. IIUC, the current direction is something like "get a packaging standard into the stdlib that people can build tools on top of" c.f. distutils/packaging. [1] And that work is not always technical. A lot of the hard work is getting people to agree on things.
-- Philippe Ombredanne
+1 650 799 0949 | pombredanne@nexB.com DejaCode Enterprise at http://www.dejacode.com nexB Inc. at http://www.nexb.com
-- Alex Clark ยท https://www.gittip.com/aclark4life/

On Thu, Jan 31, 2013 at 9:42 PM, Alex Clark <aclark@aclark.net> wrote:
I think the short answer, as always, is: getting pip into the stdlib would require a tremendous amount of work that some would have to want to do[1] before it could happen. IIUC, the current direction is something like "get a packaging standard into the stdlib that people can build tools on top of" c.f. distutils/packaging.
That's part of it, but the other part is that the 18-24 month release cycle is too long to be sensible for a tool like pip. Hence the plan to have a comparatively minimal "pysetup", whose main task would be to let people run "pysetup install pip". The relative immaturity and lack of testing of pysetup was one of the factors that led to "packaging" being dropped from 3.3 (though there were other bigger problems). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (4)
-
Alex Clark
-
Nick Coghlan
-
Philippe Ombredanne
-
Vinay Sajip