Ubuntu – python 2.7 => ImportError: No module named _io

13.04python-2.7

I decided to switch from Windows to Linux, so I installed Ubuntu Raring final beta.

Unfortunately I have a Python problem.

I was trying to use pip from a virtualenv I created, to install packages from a requirements.txt file like this: pip install -r requirements.txt

I got the following error while a package was installing: 

buildutils/initlibzmq.c:10:20: fatal error: Python.h: No such file or directory

compilation terminated.

error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

I found on internet that to get rid of this, I should install the python-dev deb package: 

sudo apt-get install python-dev

Since I installed this package, I have the following error when I try to run a python: 

file: "ImportError: No module named _io".

I use this python from the virtualenv: 
Python 2.7.4rc1 (default, Mar 30 2013, 15:39:28) 
[GCC 4.7.2] on linux2

Does anyone have an idea? I can't find anything on Google, and I really need to solve this issue in order to use Ubuntu for my work…

Thanks for your help.

EDIT:

It seems my virtualenv was corrupted for some reason. I uninstalled it.

I recreated one, and performed the "pip install -r requirements.txt" again, and now I have this error:

Warning: failed to configure libzmq:

/bin/sh: 1: ./configure: not found



staging platform.hpp from: buildutils/include_linux



************************************************

Using bundled libzmq

************************************************

building 'zmq.libzmq' extension

creating build/temp.linux-x86_64-2.7/buildutils

creating build/temp.linux-x86_64-2.7/bundled

creating build/temp.linux-x86_64-2.7/bundled/zeromq

creating build/temp.linux-x86_64-2.7/bundled/zeromq/src

x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -Ibundled/zeromq/include -Ibundled -I/usr/include/python2.7 -I/usr/include/x86_64-linux-gnu/python2.7 -c buildutils/initlibzmq.c -o build/temp.linux-x86_64-2.7/buildutils/initlibzmq.o

x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -Ibundled/zeromq/include -Ibundled -I/usr/include/python2.7 -I/usr/include/x86_64-linux-gnu/python2.7 -c bundled/zeromq/src/ipc_address.cpp -o build/temp.linux-x86_64-2.7/bundled/zeromq/src/ipc_address.o

x86_64-linux-gnu-gcc: error trying to exec 'cc1plus': execvp: No such file or directory

error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

EDIT2:

The gcc error above can be fixed by installing the build-essential package.

Best Answer

In addition to standard library and 3rd-party modules Python also has builtin modules. These are written in C and are linked directly in the Python executable. You can find out what these are like this:

$ python
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 sys
>>> sys.builtin_module_names
('__builtin__', '__main__', '_ast', '_bisect', '_codecs', '_collections', '_functools', '_heapq', '_io', '_locale', '_md5', '_random', '_sha', '_sha256', '_sha512', '_socket', '_sre', '_struct', '_symtable', '_warnings', '_weakref', 'array', 'binascii', 'cPickle', 'cStringIO', 'cmath', 'errno', 'exceptions', 'fcntl', 'gc', 'grp', 'imp', 'itertools', 'marshal', 'math', 'operator', 'posix', 'pwd', 'select', 'signal', 'spwd', 'strop', 'sys', 'syslog', 'thread', 'time', 'unicodedata', 'xxsubtype', 'zipimport', 'zlib')

virtualenv env works by copying /usr/bin/python2.7 into env/bin/python, and then symlinking all the standard library modules into env/lib/python2.7/*.py.

When you upgrade your system Python, you automatically get the updated standard library in all your virtualenvs (because symlinks!), but you're still using the old copy of the Python executable. This means you're also using the old versions of the builtin modules.

Some standard library modules depend on builtin modules. And sometimes Python 2.7.(x+1) standard library depends on builtin modules that got introduced in Python 2.7.(x+1) too. By using an old virtualenv you're in effect trying to use Python 2.7.x with the standard library of Python 2.7.(x+1), and sometimes this breaks.

Re-creating the virtualenv is the correct solution.

(It's probably sufficient to replace the bin/python and bin/python2.7 executables inside the virtualenv, assuming that no new stdlib files appeared in the updated system Python.)

Related Question