Wednesday, May 08, 2013

cannot import name MAXREPEAT

When I upgraded from Xubuntu 12.10 to 13.04 today, all my existing Python virtualenvs broke! Fortunately, they're just virtualenvs and easy to replace (that's kind of the point). But don't panic if you start seeing these.

$ ipython
Traceback (most recent call last):
  File "/home/catherine/ve/e2/bin/ipython", line 5, in 
    from pkg_resources import load_entry_point
  File "build/bdist.linux-i686/egg/", line 16, in 
  File "/home/catherine/ve/e2/lib/python2.7/", line 105, in 
    import sre_compile
  File "/home/catherine/ve/e2/lib/python2.7/", line 14, in 
    import sre_parse
  File "/home/catherine/ve/e2/lib/python2.7/", line 17, in 
    from sre_constants import *
  File "/home/catherine/ve/e2/lib/python2.7/", line 18, in 
    from _sre import MAXREPEAT
ImportError: cannot import name MAXREPEAT

Apparently Python 2.7.4 introduces _sre.MAXREPEAT. Here it is in my (new) system Python, 2.7.4:

Python 2.7.4 (default, Apr 19 2013, 18:28:01) 
[GCC 4.7.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import _sre
>>> _sre.MAXREPEAT

... but the virtualenvs I created before the upgrade still use Python 2.7.3

Python 2.7.3 (default, Sep 26 2012, 21:51:14) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import _sre
>>> _sre.MAXREPEAT
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'MAXREPEAT'

If I were a deeper hacker I'd try to figure out why code running within my old virtualenvs is trying to access a 2.7.4-only attribute, or what's the most efficient way to recover my old virtualenvs. But I'll settle for recognizing the problem and spinning up new virtualenvs instead. That fixes the problem.

I know... I could have avoided this problem by using Python 3! I've got code that depends on fabric, though, which still isn't available for 3.


Javier Tejero said...

For anyone willing to avoid recreating big virtualenvs, just run $virtualenv

And will be properly upgraded to 2.7.4.

This happily work for me...

Javier Tejero said...

You don't need to recreate the environment.
You can upgrade the virtualenv running this command:

$ virtualenv

YOUR_OLD_ENV folder will be properly upgraded to 2.7.4.

Marius Gedminas said...

In case you're curious, the error happens because the 'python' binary in the virtualenv is a copy of the old 2.7.3, while the standard library in the virtualenv is a bunch of symlinks to the new 2.7.4.

The Python binary has all the builtin modules (such as _sre) linked into it, and so when a standard library module wants to access them, things break.

Question to the other commenters: do I need to activate the old and broken virtualenv before running 'virtualenv' to fix it? Or is it enough to cd to the virtualenv root?