[TIP] Tox problems with Python 2.5, 3.1 and 3.4

[Marius Gedminas]

On Sun, Aug 25, 2013 at 12:23:27PM -0500, Skip Montanaro wrote:
> I've recently returned to a project (pylockfile) which I've let lay
> fallow for a long while. When I last worked on the project I used tox
> to run the unit test suite with Python 2.5, 2.6, 2.7, 3.1, 3.2, and
> 3.3.  This go 'round, I added Python 3.4 (cpython branch of Python
> development). Tox, pip and virtualenv were reinstalled with Python 3.4
> (though I didn't consciously mean to do that). I've reproduced the tox
> output below for the failing Python versions. Any input about how to
> solve any of these issues would be much appreciated.
> 
> Thanks,
> 
> Skip Montanaro
> 
> Python 2.5 fails with this output:
<snip>
>   Traceback (most recent call last):
>   File "<string>", line 67, in <module>
>   File "/Users/skip/local/lib/python2.5/md5.py", line 6, in <module>
>     from hashlib import md5
>   File "/Users/skip/local/lib/python2.5/hashlib.py", line 133, in <module>
>     md5 = __get_builtin_constructor('md5')
>   File "/Users/skip/local/lib/python2.5/hashlib.py", line 60, in
> __get_builtin_constructor
>     import _md5
> ImportError: No module named _md5

This tends to happen when your Python executable version doesn't match
your stdlib version.  More specifically, when you create a virtualenv,
and then upgrade the system Python.  Virtualenv symlinks the stdlib and
gets the new version, which expects a new Python binary.  Virtualenv
copies the Python binary, so you get the old one.

Is /Users/skip/local/lib/python2.5 a virtualenv, or a real Python
installation?

> Is it still possible to use tox to test w/ Python 2.5?

Yes.

> Python 3.1 fails with this traceback:
> 
> Traceback (most recent call last):
>   File "../bin/pip", line 9, in <module>
>     load_entry_point('pip==1.4.1', 'console_scripts', 'pip')()
>   File "/Users/skip/src/pylockfile/.tox/py31/lib/python3.1/site-packages/pkg_resources.py",
> line 378, in load_entry_point
>     return get_distribution(dist).load_entry_point(group, name)
>   File "/Users/skip/src/pylockfile/.tox/py31/lib/python3.1/site-packages/pkg_resources.py",
> line 2566, in load_entry_point
>     return ep.load()
>   File "/Users/skip/src/pylockfile/.tox/py31/lib/python3.1/site-packages/pkg_resources.py",
> line 2260, in load
>     entry = __import__(self.module_name, globals(),globals(), ['__name__'])
>   File "/Users/skip/src/pylockfile/.tox/py31/lib/python3.1/site-packages/pip/__init__.py",
> line 9, in <module>
>     from pip.log import logger
>   File "/Users/skip/src/pylockfile/.tox/py31/lib/python3.1/site-packages/pip/log.py",
> line 7, in <module>
>     from pip import backwardcompat
>   File "/Users/skip/src/pylockfile/.tox/py31/lib/python3.1/site-packages/pip/backwardcompat/__init__.py",
> line 125, in <module>
>     from ssl_match_hostname import match_hostname, CertificateError
> ImportError: No module named ssl_match_hostname

Sounds like a bug in pip.  https://pypi.python.org/pypi/pip still claims
Python 3.1 compatibility.

(I wouldn't be surprised if pip upstream decides that the proper fix is
to explicitly drop Python 3.1 compatibility.  I don't think anybody ever
actually used 3.1.)

> Python 3.4 fails with this output:

(I don't know anything about 3.4.)

Marius Gedminas
-- 
I actually have a user on my system named %x%x%n%n just so I can catch format
string issues in Gnome more easily.  :)
        -- Kees Cook
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20130826/bd2a825a/attachment.pgp>