System SSL settings don't carry through to virtualenv

[Jon]

SSL support in Python doesn't always work out the box, especially when using virtualenv.

You'll know you have a problem when you an error similar to the following:

AttributeError: 'module' object has no attribute 'ssl'

If you are receiving this using your system Python installation, as well as your virtualenv you'll need to follow Patrick Altman's instructions: http://paltman.com/2007/nov/15/getting-ssl-support-in-python-251/

However, after completing the above you will find that your system python passes the following quick test:

$ python
>>> import socket
>>> hasattr(socket, "ssl")
True

BUT your virtualenv:

/path/to/your/virtualenv/source bin/activate

Fails the same test:

$ python

>>> import socket
>>> hasattr(socket, "ssl")
False

It seems that virtualenv has problems picking up ssl settings, especially, in my experience, when openssl is installed after virtualenv. Creating fresh environments has no effect.

To get round the problem, try the following:

Via your system python:

$ python

>>> import _ssl
>>> _ssl.__file__

You should get a path similar to (DO NOT modify anything in this directory):

/usr/local/lib/python2.5/lib-dynload/_ssl.so

Copy or symlink that to file in your virtualenv python site-packages folder:

cp /usr/local/lib/python2.5/lib-dynload/_ssl.so /path/to/your/virtualenv/lib/python2.5/site-packages/_ssl.so

And it should all work fine. Test it in your virtualenv via the same command from earlier:

/var/odbody/uat/odbody-uat$ source bin/activate

>>> import socket
>>> hasattr(socket, "ssl")
True

I believe this to be a bug in virtualenv and have reported it as such here. Although I'd happily be proved otherwise!

(Many thanks to mgedmin in #zope3-dev for his help with this problem)

[Ian Bicking (ianb)]

So I guess the problem in this case is that /usr/lib/python2.5/lib-dynload is being symlinked over, and so it will work, but /usr/local/lib/python2.5/lib-dynload is not.

These directories aren't determined in site.py, but sometime earlier (which is why the symlink is necessary). However, stuff in /usr/local/ probably isn't as critical, so it can be added at a later time.

I think I've fixed this in r3804. It doesn't copy over anything from lib-dynload, but should add that to the path.

[Carl Meyer (carljm)]

Not migrating to new tracker at https://github.com/pypa/virtualenv/issues - appears to be fixed.