PythonAnywhere + virtualenv: "Could not find platform dependent libraries <exec_prefix>..."

Question

I have a Django (1.5.1) site running on Python 2.7.3 in a virtualenv at PythonAnywhere. As far as I remember, everything used to work fine. Lately, although I haven't changed anything except some Django code, I get the following message when I run pip:

(venv)11:34 ~ $ pip
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Traceback (most recent call last):
  File "/*~*//venv/bin/pip", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/*~*//venv/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py", line 16, in <module>
    import sys, os, zipimport, time, re, imp, types
ImportError: No module named time

Needless to say, pip does not work at all after producing the above error.

When I run python with the virtualenv activated, I again get the following error:

(venv)11:34 ~ $ python
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Python 2.7.3 (default, Apr 29 2013, 15:12:04) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Traceback (most recent call last):
  File "/*~*//.pythonstartup.py", line 1, in <module>
    import rlcompleter
ImportError: No module named rlcompleter
>>>

But, thereafter, the Python console appears to be in working order.

Without the virtualenv activated, python runs fine without any errors.

All was well a couple weeks ago when I last ran pip and installed some packages, but now, pip is not working, although all of my Django site's features run just fine. I appreciate any ideas that could get pip to work again.

Answer 1

There's definitely something fishy going on if it can't find module time - as far as I'm aware that module is actually built in to the Python binary itself so it's not as if there's a time.py or time.so file which could have been deleted. It looks as if either Python in your virtualenv has become broken somehow, or there's something about the environment that's messing it up.

Setting a dubious PYTHONHOME variable can cause Python all sorts of trouble as it can't find necessary files, but I think in this case it's the fact that the virtualenv has become broken. In fact, I just tried an old virtualenv on PythonAnywhere myself and got the same issue. It looks as if the symlinks that virtualenv creates have become broken as the result of an upgrade, possibly the recent upgrade from Debian to Ubuntu.

If at all possible I would simply re-create a new virtualenv and run things from there. In principle you could use pip to write a requirements file so you can create a new virtualenv with exactly the same versions of the code, but the problem is that you can't run pip to create this file, QED. There's probably a clever way to use the system Python to run pip and get the dependencies from your virtualenv, but it's going to be tricky - it's not designed to work that way.

Alternatively you could contact the PA devs - I know that some users did have problems with their virtualenvs around the time of the upgrade and they may have cunning scripts which can fix the problem. Even if you just build a new virtualenv and use it, I would contact them and make sure they know about this issue so they're aware of it for future upgrades.