Empty Thoughts

Since I published my introductory post on the project, I have not posted any additional updates regarding the project. Quietly, there’s been tons of work happening, and so I thought I would give some visibility to all of the great contributions to the effort.

As a review, the django-command-extensions project is a repository for collecting global custom management extensions for the Django Framework.

Since the project was started there has been an additional twelve commands added. The bulk of the work has been headed up by Ido Sebastiaan van Oostveen, with some additional work by Doug Napoleone and Ludvig Ericson. Personally, I haven’t had much involvement in the development beyond a few initial commands. Although, I have been a satisfied customer of the extensions, such that it has become a staple for all of my Django projects.

So on to the fun stuff. Here’s a list of commands in the project:

• create_app – creates an application directory structure for the specified app name. This command allows you to specify the --template option where you can indicate a template directory structure to use as your default.

• create_command – creates a command extension directory structure within the specified application. This makes it easy to get started with adding a command extension to your application.

• create_jobs – Creates a Django jobs command directory structure for the given app name in the current directory. This is part of the impressive jobs system.

• create_superuser – makes it easy to create a superuser for the django.contrib.auth.

• describe_form – used to display a form definition for a model. Copy and paste the contents into your forms.py and you’re ready to go.

• – export the email addresses for your users in one of many formats. Currently supports Address, Google, Outlook, LinkedIn, and VCard formats. I have found this really handy.

• generate_secret_key – creates a new secret key that you can put in your settings.py module.

• – creates a GraphViz dot file. You need to send this output to a file yourself. Great for graphing your models. Pass multiple application names to combine all the models into a single dot file. This one is very useful with lots of options for flexibility. See the wiki page for detailed information.

• passwd – makes it easy to reset a user’s password

• run_job – run a single maintenance job. Part of the jobs system.

• run_jobs – runs scheduled maintenance jobs. Specify hourly, daily, weekly, monthly. Part of the jobs system.

• runprofileserver – starts runserver with hotshot/profiling tools enabled. I haven’t had a chance to check this one out, but it looks really cool.

• shell_plus – An enhanced version of the Django shell. It will autoload all your models making it easy to work with the ORM right away. I use this every day. It is so handy.

• show_urls – displays the url routes that are defined in your project. Very crude at this point.

• sqldiff – prints the (approximated) difference between an apps models and what is in the database. This is very nice, but also very experimental at the moment. It can not catch everything but it’s a great sanity check.

On the documentation front, Ido has been actively putting together some and usage instructions to help people get started. We still have quite a few undocumented commands so if you would like to pitch in, we appreciate your help.

If you like using Mercurial, Ido maintains a Mercurial repository for the project. You can find more information on using his repository on the .

I would like to thank Ido Sebastiaan van Oostveen for his help. He’s really taken a leadership role and contributed a lot of great stuff. Additionally he’s been fleshing out the documentation and managing the tickets / patches.

Finally, if you would like to get involved in the project, we’re always looking for people to help out. Feel free to . If you would like to contribute directly, please let me know.

I had a need to generate a new secret key for a Django project that I’m working on. Often when I start a new project I’ll just copy an existing project template that I have which has all the bits and pieces in the right places. This helps me to get going quickly without a lot of fuss. Although when doing so I always need a new SECRET_KEY for the settings file. Instead of doing it manually this time, I decided to create a new custom management command and make it part of my global . For doing this I just inherited from the NoArgsCommand and extracted the logic for creating the secret key from the startproject command in the Django source.

from random import choice
from django.core.management.base import NoArgsCommand

class Command(NoArgsCommand):
    help = "Generates a new SECRET_KEY that can be used in a project settings file." 

    requires_model_validation = False
    can_import_settings = True

    def handle_noargs(self, **options):
        return ''.join([choice('abcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*(-_=+)') for i in range(50)])

While creating the most recent Django Screencast on Custom Management Commands, I had it in my show notes to mention how you can call Django’s management commands from an external script. There’s probably several different ways to accomplish this, but the simplest and “baked in” way to do this is through the use of the call_command function. This function is part of django.core.management.

For example, if we wanted to call sqlall from the shell we could do something like the following:

>>> from django.core.management import call_command
>>> call_command('sqlall', 'delinkuent')

The call_command function’s signature looks like:

call_command(name, *args, **options)

It accepts the name of the command we’re executing, any required arguments, and options to the command. If we have a command with an argument and options it might look like the following:

>>> call_command('say_hello_name', 'michael', capitalize=True)
Hello Michael

This approach works fine with any custom management commands you may have created as well.

There is a caveat to this approach. You must be sure that you’ve properly set up your DJANGO_SETTINGS_MODULE environment variable. For more information about this see James Bennett’s excellent writeup on the subject.