Forums

Hi, I've just realized that my django application is not using my virtualenv, but the outer python environment!

Inside "myvirtualenv" I have python3.4 and Django1.7.1 (and everything works fine when I activate it in a bash shell), but when any error appear while I'm visiting a web page I get the following (not to say that these errors are probably due to the wrong virtualenv):

KeyError at /user/list/

Request Method: GET
Request URL:    http://sirion.pythonanywhere.com/user/list/?reload=1
Django Version: 1.6.6
Exception Type: KeyError
Exception Value:     ...
Python Executable:  /usr/local/bin/uwsgi
Python Version: 3.3.6
Python Path:    
    ['/home/Sirion/.virtualenvs/myvirtualenv/lib/python3.3/site-packages',
     '/var/www',
     '.',
     '',
     '/home/Sirion/.local/lib/python3.3/site-packages',
     '/usr/local/lib/python3.3/dist-packages/setuptools-7.0-py3.3.egg',
     '/usr/local/lib/python3.3/dist-packages/matplotlib-1.3.1-py3.3-linux-x86_64.egg',
     '/usr/local/lib/python3.3/dist-packages/certifi-14.05.14-py3.3.egg',
     '/var/www',
     '/usr/lib/python3.3',
     '/usr/lib/python3.3/plat-x86_64-linux-gnu',
     '/usr/lib/python3.3/lib-dynload',
     '/usr/local/lib/python3.3/dist-packages',
     '/usr/lib/python3/dist-packages',
     '/home/Sirion/defeatme']
Server time:    Wed, 28 Jan 2015 10:46:59 +0000

The path '/home/Sirion/.virtualenvs/myvirtualenv/lib/python3.3/site-packages' does not even exists on server!

In my wsgy.py I have:

activate_this = '/home/Sirion/.virtualenvs/myvirtualenv/bin/activate_this.py'
with open(activate_this) as f:
    code = compile(f.read(), activate_this, 'exec')
    exec(code, dict(__file__=activate_this))

Moreover, I do not find any error or warning in error.log file. Is there something I'm missing?

The current solution we have for virtualenvs only adds your virtualenv to the path, it doesn't remove the system packages. It should mean that your virtualenv packages have priority, but the system ones are also available. That can cause strange bugs when a package in your virtualenv shadows a system package, or when you forget to install a package into your virtualenv and you unexpectedly get the system one instead.

We're testing a better solution for virtualenvs which we hope to be releasing in the next few weeks.

In the meantime, I think your bug is unrelated ;-)

Thanks for the quick answer, but I'm still wondering how is it possible to get this path:

 '/home/Sirion/.virtualenvs/myvirtualenv/lib/python3.3/site-packages'

I think that the key of the problem is there...

In the meantime, is there a way to update python from 3.3 to 3.4 in the outer environment (i.e. the python version I chose when I created my webapp)? I've already installed python3.4 but it is not the default version; in Web tab I see: "Python version: 3.3"

Is it possible that you accidentally created your webapp with python3.3 instead of 3.4? What does it say on the web tab?

I did create my webapp with python3.3 since python3.4 did not exist at that time. But since I can't have virtualenvs work properly (no idea why) I was wondering if it were possible to update the outer environment (in order to use that).

try deleting and re-creating your web app. It will back up your old wsgi file in /var/www using the .bak extension, so use "manual configuration" when you recreate it, copy the old wsgi configuration in, and see if it works any better?

What about the mysql database, how can I save it?

When Harry said "deleting and re-creating your web app" he was talking about the red "Delete..." button on the "Web" tab -- that doesn't delete any of your files or your data, it just shuts down the app and moves the WSGI file to one side. So your MySQL database should be fine, as should your code.

If you want to back up your database anyway, then you can do that using the mysqldump command from a bash console

I created a new webapp with python3.4 and the faulty path above became:

 '/home/Sirion/.virtualenvs/myvirtualenv/lib/python3.4/site-packages'

which is eventually right.

:-)

Hi everyone, we've just released a new way to handle virtualenvs which should avoid the system-site-packages / shadowing issues. There's an overview here and a guide switching across from the old system here