[CentralOH] virtualenv / wsgiref

Eric Floehr eric at intellovations.com
Mon Nov 8 20:38:11 CET 2010


Mark,

I'm trying to learn virtualenv (thanks, Austin). I setup a virtual
> environment with no-site-packages. When I do a pip freeze, it shows
> wsgiref==0.1.2. This happens on both my Mac (default Python install on OSX
> 10.6.4) and on Ubuntu 10.10.  Is wsgiref a requirement of virtualenv?
>

The --no-site-packages option only turns off global site-packages.  If you
have anything locally installed, or outside of site-packages, it will still
pick it up.  You can look at your pythonpath by starting python in your
virtualenv and:

>>> import sys
>>> sys.path

You can see, for example, that "/usr/lib/python2.6" is on the path, and if
you look in that directory you'll notice a wsgiref.egg-info and a wsgiref
directory.  dpkg (on Ubuntu 10.04) shows:

# dpkg --search /usr/lib/python2.6/wsgiref.egg-info
python2.6: /usr/lib/python2.6/wsgiref.egg-info

That the file is installed as part of the core python 2.6 package.  As it
turns out, wsgiref was added to the python distribution in version 2.5 (
http://docs.python.org/release/2.6/library/wsgiref.html) and because its
distributed as a package (the egg-info file, and not just a set of python
standard modules), that's why pip is picking it up.  Seems to me to not be
ideal behavior.

Also, on my Mac, if I launch Python in the virtual environment, as expected,
> libraries installed in my site-packages directory are not available;
> however, if I launch idle from within that virtual environment, those
> libraries ARE available. I assume that the idle launch script somehow
> restores the default environment.
>

If you look at /usr/bin/idle (or wherever the idle script is installed on
Mac) you'll see it has at the top a she-bang with /usr/bin/python:

#! /usr/bin/python

Which means its running in the global environment.  This is a "bug" on
idle's behalf (probably should submit a bug)... this should more properly
defer to the environment and be:

#! /usr/bin/env python

Which is the standard approach for portability.  Please definitely submit a
bug report to make things better :-)!

Best Regards,
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/mailman/private/centraloh/attachments/20101108/54035b89/attachment.html>


More information about the CentralOH mailing list