Category: Django

  • The Django Shuffle

    Lots of changes are happening in the newly formed Django world these days. Tons of bugfixes and feature additions have been streaming in to the subversion repository. One of my recent favorites is Changeset 384 which adds a django-admin.py inspectdb command. It’s not perfect yet but it should help out people trying to integrate existing databases with Django. The new command will do its darndest to output a Django model given a particular database name.

    In other news, congrats to Eric (slashzero) on the new gig in Naples and to Adrian (adrian_h) on his new gig at The Washington Post.

    Update: Hugo’s at it again and has notes on using Django with Apache and mod_fcgi which build on his experience with Django, lighthttpd and FastCGI.

  • Django on Dreamhost via FastCGI

    Thanks to the hard work by Hugo and an excellent efford by skabber and jdanks, there are now instructions for installing Django on Dreamhost using FastCGI on the Dreamhost Wiki.

    I’m still amazed at how quickly Django development is happening and how quickly a community is being built out around it. Keep an eye on the Django Trac timeline for a glimpse at the latest and greatest.

    Update: Sorry about the mislink, Jay.

  • Django + lighttpd + FastCGI

    Hugo has taken the plunge and provides installation instructions for Django + lighttpd + FastCGI. Thanks, Hugo!

  • Django: Trivial Patch

    Last night I ran across a deprecation warning when running django-admin.py startproject <projectname>, so I went to file a ticket but found that someone else had experienced the same problem. I looked at the solution, and on the surface it looked like the fix involved replacing from whrandom import choice to from random import choice. Indeed that was all it took, so I submitted a (trivial) patch and continued to bang on Django a bit more.

    That trivial patch made me really wish that there were unit tests for Django. I would have felt a lot better knowing that after applying my patch n tests still passed with flying colors. Without a test framework in place, I really had no idea if my trivial search and replace broke something. It’s possible that somewhere in the code was really expecting some behavior specific to whrandom that was just slightly different than the behavior of random.

    I’m going to hunt around for other little trivial fixes that don’t require carnal knowledge of the codebase and submit patches if I can come up with a fix. At the same time I hope that Nelson’s test suite ticket gets noticed. I wouldn’t mind doing some of the dirty work once a framework is in place, but as always I defer to Adrian and the core Django team when it comes to policy and implementation.

  • Keeping Up With Django

    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 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. Strike that, you still need the environment variable, the name is just user configurable. (Thanks Stefano!) And of course the addition of 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.

    Update:

    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.

  • Pimp My Django

    Pimp My Django

    Yeah, baby! Thanks to tons of SVN updates, I’ve managed to plow through the second Django tutorial unscathed. I’m really impressed with the admin interface and how a dab of Python can do stuff like create a sidebar or create a rocking search interface.

    Huzzah!

  • Django: Making it Easier

    Yes! Adrian has just commited a patch that bypasses mod_python completely!

    mcroydon@mobilematt:~/django/proj$ django-admin.py runserver
    Starting server on port 8000. Go to http://127.0.0.1:8000/ for Django.

    svn up in your django_src dir and enjoy.

  • Django Gotchas

    I know that a lot of these things will get ironed out or explained more clearly once the platform matures and more people start using it, but here are some tips for early Django adopters trying to get through the tutorials:

    1. Don’t name your project test. I know it sounds like a good idea now. I did the same. Trust me though, at the beginning of Tutorial 2 you’ll start kicking yourself when you run in to namespace collisions with the test module. In order to make this warning a bit more abstract, you’re best off not naming your project anything that is a Python module in the Python Standard Library
    2. Your project directory should be somewhere in your Python Path. Under Linux your best bet is to set the PYTHONPATH environment variable. Here’s the gotcha, if your project is in /path/to/project, you actually want to set your PYTHONPATH variable to /path/to. On a per-session basis you can do this by doing something like export PYTHONPATH=/path/to
    3. In order to really use django-admin.py as often as you’re going to, you really want to symlink it to /bin or /usr/bin. For me (again, under Ubuntu having checked out Django via Subversion), ln -s /usr/lib/python2.4/site-packages/django/bin/django-admin.py /usr/bin/django-admin.py did the trick.
    4. Really pay attention to the install instructions and make sure you symlink your django install to /usr/lib/python/site-packages correctly.
    5. I’m still dealing with the newbie cookie authentication bug that tends to creep up partway through the second tutorial, but I was able to get the admin login to pop up by using the following settings for Apache2 and mod_python (with special thanks to #django and the Django on OSX installation guide):
      <location /admin/>
              SetHandler mod_python
              PythonHandler django.core.handler
              PythonPath sys.path+['/home/mcroydon/django']
              SetEnv DJANGO_SETTINGS_MODULE proj.settings.admin
              PythonDebug On
      </location>

      The PythonPath to the directory containing your project is again quite critical. This is where the test collision will show up if you’ve been foolish enough to name your project test. Make sure that DJANGO_SETTINGS_MODULE points to your project. This worked perfectly for me under Ubuntu Hoary, but YMMV. PythonDebug On is your friend here and turns a plain jane 500 error into a traceback.

    Gotchas like these are going to have to be minimized in order to not scare away newbies and also enable that “running start” feeling that you get with Rails. I’m sure that a few of these are mitigated by setup.py in the tarball and the rest should be made a lot easier once WSGI support is added (and I’m glad to hear that adding a built-in server is on the list somewhere) should take care of the rest.

    I do have to say that so far (gotchas aside) I’m really impressed with the platform. It’s great to be able to work with the Python interpreter to flush out some test data (you can do similar things with the Ruby interpreter with Rails, but Python is my native language). I also got warm fuzzies when someone asked if there was a mail module for Django. Heck, Python has an awesome standard library, why not use it?

    Thanks again to everyone in #django on Freenode for all the help and guidance. Now it’s time to get back to that login gotcha.

    Note: Django is a moving target right now. Since I wrote this early this morning, support for a standalone server has been added (just after WSGI support was added) and lots of little bugs and niggles are being taken care of as I type.

  • Django: Python on Rails?

    Let the buzz over Django begin. I first saw it fly by very early this morning as Clint Ecker pointed to some documentation. Simon Willison has given it a proper introduction this morning.

    I definitely need to take a close look at Django if it can approach the productivity of Rails while speaking my native Python. I could be missing something, but I think one very important thing that Django needs in order to have that running start in development productivity is to ship with a small HTTP server available by default. Rails uses WEBrick for this and allows development without the need to mess with Apache or lighttpd in order to start coding. It should be trivial to add similar functionality to Django (with CGIHTTPServer and all).

    I don’t mean to rag on the new framework on the block. I think Django has a ton of potential. It’s off to the right start, having been extracted from a working environment being worked on by some really smart people.

    We’ll see how this turns out, but I’m extremely excited.