Forums

I started dev on localhost using django 1.4

I'm running into issue as try to upload my web app from the desktop to your network. Here is the error it got.

[Fri Jun 08 17:13:41 2012] File "/usr/local/lib/python2.6/dist-packages/Django-1.3.1-py2.6.egg/django/utils/dictconfig.py", line 352, in configure [Fri Jun 08 17:13:41 2012] '%r: %s' % (name, e)) [Fri Jun 08 17:13:41 2012] ValueError: Unable to configure handler 'mail_admins': Unable to add filter 'require_debug_false': 'require_debug_false'

After search around, I realized that pythonanywhere support django 1.3.1 and I built my app on 1.4.

What are my options now?

Update I can get past some of these errors, but eventually run into more.

I'm still wondering what my options are and if I get get Django 1.4 access? (I don't have too many dependencies aside from BeautifulSoup-3.2.1)

-sp

You can set up a virtualenv and install Django 1.4 into it. In a bash shell do this:

export WORKON_HOME=~/Envs
mkdir -p $WORKON_HOME
source virtualenvwrapper.sh 
mkvirtualenv django
pip install django

It will create a virtualenv in ~/Envs/django. The pip install took a REALLY long time, so have a little patience there. You can also then do

pip install beautifulsoup

to get beautifulsoup installed in the virtualenv

Once you've got the virtualenv setup, you need to tell PythonAnywhere to use it and to serve your app. Edit your wsgi file (Go to the Web tab on the dashboard and click on the 'Existing apps & other WSGI frameworks'). The code below assumes that your Django app is in /home/sampatel/newdjango. Just change the instances of newdjango to match the actual location of your app.

# This activates the virtualenv for this script
activate_this = '/home/sampatel/Envs/django/bin/activate_this.py'
execfile(activate_this, dict(__file__=activate_this))

import os
import sys

if '/home/sampatel/newdjango' not in sys.path:
    sys.path.insert(0, '/home/sampatel/newdjango')

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "newdjango.settings")

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

Wow - I wan't expected to have a solution. And code to go with it. Amazing customer service... I must get a paid account soon. Thanks so much - this worked great!

Excellent. Glad to help.

Thanks for this excelent solution. But i'll ask one more question because i haven't use virtualen before.

So:

Do i have to replace the entire wsgi code with the given one.

Then, how do i put my project's files (in another word, how do i organize my directory structure).

Thanks in advace.

Hi medreda -- yes, you just replace all of the code in /var/www/wsgi.py with the code that glenn gave (though with "sampatel" replaced with "medreda", of course). Your project's files then go in a subdirectory of your home directory -- /home/medreda/newdjango or something like that -- with the normal Django structure. Once that's set up, just his the "Reload web app" button on the "Web" page of your dashboard, and everything should work.

Hello again, i just modified the file wsgi and kept the normal directory structure (used by the default django1.3) as you told me.

But i had this error this time: ImportError: Could not import settings 'expert2.settings' (Is it on sys.path?): No module named expert2.settings

" expert2 is the name of my project. "

i have tried a lot of things but no way.

So, pending your reply i will try to deploy my project under the default django.

Best Regards

Hi medreda -- I'm a little confused, would you like to use Django 1.3 (our default) or 1.4?

If you like, I could take a look at your app and see what the problem is.

Aha, I just went to your web app (that is, the public page) and I see that you've got it working.

Thinking about it, I suspect that the problem was that your app was in /home/medreda/expert2, meaning that the settings.py file was in /home/medreda/expert2/settings.py, but when following our instructions above you put /home/medreda/expert2/ into the sys.path. I'm guessing that because it''s a common confusion, and would not have been helped by the fact that our WSGI file for sampatel above was for a situation where his app was one directory level deeper.

Hello again ;

I have deployed my web app under the default django version (1.3) just to keep my self busy. :)

i will give it another try according to your last message.

Sounds good! If you have any problems, just let us know.

Thank you both very much for the question and answer. This fixed my problem I was having as well. :3

Thanks for the steps re. how to get Django 1.4 going. Regarding virtualenvwrapper, the workon command doesn't work. Must I set up stuff in .bashrc as per http://virtualenvwrapper.readthedocs.org/en/latest/install.html#shell-startup-file or similar?

What's the error message that you get when you run workon?

I just get a bash: workon: command not found, have tried it both when an environment is activated and at a plain bash prompt.

Did you run this command:

source virtualenvwrapper.sh

?

Great Help. Working fine.

I ran the commands above to create a virtualenv in ~/Envs/django142. Now I'm in my home directory and want to use workon to list available virtual environments. Have tried source virtualenvwrapper.sh, but get bash: fmt: command not found. Apologies if I'm missing something obvious or just confused.

I'm not sure about that. It looks like virtualenvwrapper is trying to report something to you. The report uses the fmt command and we don't make that available to our consoles (This is a bug and we'll get that fixed soon). I can't work out what it's trying to report, though.

Does workon work for other users? I mean is this happening because I've messed something up? Or do you mean that because fmt doesn't work yet, workon doesn't work for anyone? Thanks

When I tried to test my virtualenv setup, it worked fine. The lack of fmt means that it's really difficult to work out what's going on, though. Could you try using the instructions above from scratch and post the console output here?

I am having a problem similar to medreda. I had to install Django 1.4 in virtualenv as well, and I modified the wsgi file appropriately to read:

if '/home/mgh14/Dropbox/sv' not in sys.path:
    sys.path.insert(0, '/home/mgh14/Dropbox/sv')

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings")

where 'mysite' is the name of the application and 'sv' is the name of the module. Both the 'mysite' and 'sv' folders are located in '/home/mgh14/Dropbox/sv' (note that 'sv' is also the name of the containing folder: the path to the sv module is 'home/mgh14/Dropbox/sv/sv'). When I look at the error log, I get the following:

Internal Server Error: / <Traceback error information> ImportError: No module named sv

I have also tried '/home/mgh14/Dropbox/sv/', but the same error occurs. Any ideas?

By the way, I tried switching the containing folder to 'voter' instead of 'sv'. The filepath is now '/home/mgh14/Dropbox/voter', still containing the 'mysite' and 'sv' folders.

It sounds like you've got an import sv somewhere, but because the directory sv is on your sys.path, it will never find that. You either need to point your sys.path to /home/mgh14/Dropbox or change the import.

I followed this and it seemed to go without problems, but now django can no longer find static files.

Hey evilkillerfiggin,

You might want to check out the other forum posts about static files in Django. Also we are quite close to releasing proper support for static files. Should be coming any day now.

Fixed. Rock on!

I fallowed the steps. Then i uploaded file by file to the new project folder. Exactly the same structure they have in my home pc. Then i closed bash. wrote:

>>> import django                                                                                          
>>> django.get_version()                                                                                   
'1.3.5'

So whats up? when i try:

10:32 ~/djproject $ python manage.py syncdb

i get

....ValueError: Unable to configure filter 'require_debug_false': Cannot resolve 'django.utils.log.RequireDebug
False': No module named RequireDebugFalse

Hi Mihkell, it looks like you haven't activated your virtualenv. Each time you start a new console, you need to activate the virtualenv. You can tell it's worked because it changes the Bash prompt.

Have a look at the discussion here:

https://www.pythonanywhere.com/forums/topic/449/#id_post_3078

Tryed it in every folder(with every foldername :D ) getting same error:

ERROR: Environment 'FOLDERNAME' does not exist. Create it with 'mkvirtualenv FOLDERNAME'.

wanted to make it work directly with my project that i imported. Made a new project and got it to work.

Here's an official guide to setting up a web app in a virtualenv on PythonAnywhere... being served up from a web app running in a virtualenv on PythonAnywhere:

http://virtualenvdemo.pythonanywhere.com/

Thanks this was really helpful. Do you plan to upgrade the default version of django to 1.4? Perhaps could there be a way we specify this without having to install it in virtenv?

We definitely will upgrade to 1.4 -- the problem is doing so without breaking all of the 1.3 apps people are running here. We're working on a solution to that, but it's tricky...

Everything PA does is tricky...☺

Oh, yeah and awesome too!

Hello everyone! I just tried to install Django 1.4 and I got this message:

Downloading Django-1.5.tar.gz (8.0MB): 8.0MB downloaded
Running setup.py egg_info for package django
warning: no previously-included files matching '__pycache__' found under directory '*'
warning: no previously-included files matching '*.py[co]' found under directory '*'
Installing collected packages: django
Running setup.py install for django
changing mode of build/scripts-2.7/django-admin.py from 664 to 775
warning: no previously-included files matching '__pycache__' found under directory '*'
warning: no previously-included files matching '*.py[co]' found under directory '*'
changing mode of /home/Doublerainbow/.virtualenvs/django14/bin/django-admin.py to 775
========
WARNING!
========
You have just installed Django over top of an existing
installation, without removing it first. Because of this,
your install may now include extraneous files from a
previous version that have since been removed from
Django. This is known to cause a variety of problems. You
should manually remove the
/usr/local/lib/python2.7/site-packages/django
directory and re-install Django.

What should I do?

Thanks in advance! :)

[Edited by admin to format error message properly]

Sounds like your user-installed version is clashing with the system-installed version, but I'm not enough of a Django expert to advise on that. Are you using a virtualenv as documented in the demo page linked above? Are you following the instructions exactly?

One other question -- what's the command that you used to install Django?

Hello Cartroo and giles,

thanks for your answers! I used this guide and followed it exactly.

http://virtualenvdemo.pythonanywhere.com/

After it didnt work the first two times, I deleted everything on my account and tried it again. Same error.

Then I created a new account because I thought it had to do with some old files I installed earlier (I already wrote a message to support reg. deleting the old account) but I still get the same error.

PS: I also find it weird that it says Downloading Django-1.5.tar.gz (8.0MB): 8.0MB downloaded when I try to install django 1.4....

Thanks for that -- I took a look at your website, and it seems to be OK -- do you agree? I think the error you're getting is spurious -- because you've put Django in a virtualenv then none of the default Django stuff should affect you.

The problem with it downloading 1.5 is a great point, thanks for pointing that out. The virtualenv tutorial just downloaded whatever the latest version of Django was, and they released 1.5 just the other day. I've updated it so that it explicitly specifies 1.4.

Is there something wrong with using 1.5?

Still haven't upgraded any of my personal projects to using 1.5 so... couldn't say yet. I think I might try doing the full conversion from 1.4 to 1.5 and Python 3...

Now you're talkin'. I'm a bit surprised how long the delay to embrace Py3k has been in the community at large.

Python 3.0 final was released on December 3rd, 2008. Wow, it will turn 5 this year!!

On the subject of Python 3, has anybody tried to update any C extensions which do extended string manipulation for Python 3? I can imagine that having to support unicode makes that pretty tricky... I wrote a fast (and more flexible) replacement for shlex.split() in the past in pure C (for an employer, not open source) and I can imagine that sort of thing becomes a whole lot trickier with unicode objects.

For one thing, I don't think you can even assume wchar_t support if you want to target all platforms... Although I'd assume all the popular ones have it.

@Doublerainbow -- as far as I can tell, it's safe to ignore that warning from Django. I've updated the instructions, see

http://virtualenvdemo.pythonanywhere.com/#note

Took me a while to notice that the wsgi file is located in /var/www/<username>_pythonanywhere_com_wsgi.py.

This means the PROJECT_ROOT idiom like:

PROJECT_ROOT = os.path.abspath(os.path.dirname(__file__) + "../../")

will not work!

Might be worth pointing out in the wiki article on how to set up django with a virtualenv.

Interesting, I've not seen that idiom before. But it totally makes sense. I've change the line that says

Now edit your wsgi file (from the link on the "Web" tab) -- you'll need code like this for Python 2.7

...to say

Now edit your wsgi file (from the link on the "Web" tab, or by navigating to it in the file browser -- it's in /var/www) -- you'll need code like this for Python 2.7

Hopefully that will be enough to warn other people who might run into the same problem.