Peter's picture

Hello!

Starting, I would like to thank you for the great concept and work on turnkeylinux. I'm just a dabbler in web programming and webdesign doing the odd job for some non-profit organizations (well actually just for the fun of it) and the appliances make it easy to get up to speed and start with the fun part without having to work through truckloads of system settings and optimizations.

I am currently testing the Django RC (after toying with TKL GAE SDK) and seem to be stuck getting the development settings to work as Alon has described.

I tried setting DEVELOPMENT=True in /etc/environment. After reboot, the python console sure enough shows os.environ.get("DEVELOPMENT", None) as true, as does the manage.py runserver command (which loads settings_dev.py). Alas, nothing changes the behaviour of the apache installation. What do I miss here? Any suggestions would be greatly appreciated.

PS: I like to do work over ssh using vim directly on the vm. Therefore I prefer the full version (for syntax highlighting etc). Installing it is straight forward UNLESS you run into the symlink at /usr/local/bin/vim which is still pointing to vim.tiny. It took me some time to figure that out. Nothing too complicated, but worth to mention it somewhere, should anyone run into the same trap.

Forum: 
Peter's picture

When trying to set DEBUG = True in settings.py and restarting apache (by means of 'apache2ctl graceful') it went into debug mode without any problems. So it seems that for some reason apache and/or wsgi can't see the DEVELOPMENT environment variable.


Alon Swartz's picture

Hi Peter, sorry for the late reply.

I only set DEVELOPMENT when using ./manage runserver, as it's much better than a real web server while doing development (provides verbose output, automatically reloads your code when changed, etc.).

If for some reason you still want to use Apache and enable DEVELOPMENT mode, you could add this to the apache django configuration:

SetEnv DEVELOPMENT True

Hope the above helps.

Peter's picture

I usually do development with runserver as well, I just needed a quick way to check some bug I suspected resulting from the deployment system and wanted a more comfortable output than the error.log.

You solution worked.


Add new comment