It’s been quite amazing watching this framework called Django, pulled from a production environment, evolve in realtime right before my eyes. Adrian has been committing changes left and right, fixing bugs, adding features, and most importantly lowering the barrier for new users. Docs and tutorials are being clarified, things made simpler, and a few of those nagging problems are dissapearing in front of my eyes.
Yesterday Adrian modified the cookie system so that we didn’t have to add a custom setting in order to make it work.
He’s also moved Strike that, you still need the environment variable, the name is just user configurable. (Thanks Stefano!) And of course the addition of
DJANGO_SETTINGS_MODULE to a Python variable so you should no longer have to set an environment variable in order to tel the system which module you want to run.
django-admin.py runserver lets you bypass
mod_python or another WSGI-compliant server while you are just checking out the framework or during initial development.
jango team and everyone in the quickly expanding community. If you’re having trouble with something, hop on #django at Freenode, there’s probably someone else in there who has experienced the exact same thing. And don’t forget to
svn up often!
Now that I’ve gone through the tutorials and have reasonably wrapped my head around the framework I plan to work on a small project to flex my newly found Django muscles.
As always, Adrian has made our lives simpler, this time with Changeset 247:
Added ‘–settings’ option to django-admin. This specifies which settings module to use, if you don’t want to deal with setting the DJANGO_SETTINGS_MODULE environment variable. Refactored django-admin to use optparse. Updated the tutorials to use ‘–settings’ instead of environment variables, which can be confusing.