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, infrom pkg_resources import load_entry_point File "build/bdist.linux-i686/egg/pkg_resources.py", line 16, in File "/home/catherine/ve/e2/lib/python2.7/re.py", line 105, in import sre_compile File "/home/catherine/ve/e2/lib/python2.7/sre_compile.py", line 14, in import sre_parse File "/home/catherine/ve/e2/lib/python2.7/sre_parse.py", line 17, in from sre_constants import * File "/home/catherine/ve/e2/lib/python2.7/sre_constants.py", 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 4294967295L
... 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.
3 comments:
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...
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.
http://stackoverflow.com/questions/16270024/no-module-name-datetime-after-ubuntu-13-04-upgrade
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?
Post a Comment