Since I published my introductory post on the django-command-extensions 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
--templateoption 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_emails – 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.
- GraphModels – 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
runserverwith 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 installation 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 wiki page.
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 submit patches or bug / enhancement reports. If you would like to contribute directly, please let me know.
I wrote a command a while ago to dump all database data for a given app to stdout, as a python script that will recreate the data. This is helpful in development, as autofields are ignored, foreign keys are linked and the resulting file easier to edit, update, loop to create formidable test data and wont break when new fields are added to the data model.
Of course, it now needs to be slightly modified after the queryset-refactor merge (parent entries are unnecessary), but it would be good to get it out in the wild. Let me know if you’re interested and I’ll send you the file.
Cheers,
Will
Will, that sounds great. It would be a very nice addition. Why don’t you send me the patch or just upload it to the Issues.
this is quite a great tool! the GraphModels is very impressive
Will, that sounds really helpful. If it can run multiple times without inserting duplicate data it could also be easily turned into a python format for fixtures with the post_syncdb signal.
Feature request. Is it possible to create a command to export some tables into fixtures (for example json fixtures) ?
Nick; You mean like the dumpdata command does ?
Hmm, yes, dumpdata will work for me, thank you. But I always got ‘Serialization error’ on Mysql.
I uploaded the file to your issue tracker, I can send you some test data too if you’d like…
Re: running it multiple times: that’s probably more the role of a fixture, because my script wont specify autofields. But it would be trivial to add a check for any existing data by matching the unique fields. It’s probably a good idea anyway, because unique fields should never be added twice: I’ll add it when I next work on the script.
Cheers,
Michael,
You speak of the ‘impressive jobs system’. For one of my projects I am planning to build a management console for managing scheduled jobs. In this blog entry this triggered my interest, however, I have been unable to locate any information (or code) for this system. Is it part of the current Django Trunk?
Marcel: sorry I wasn’t clear. Ido has actually implemented a way through the jobs management commands to set up jobs that are then processed on a periodic basis. This is not part of standard Django, but something Ido added. It’s probably not the level of what you’re looking for, but maybe it is.
Marcel,
The current job systems allow for creating jobs in much the same way as you can create commands for every Django App and there’s also support for Ian’s dispatcher style jobs.
The biggest limitation at this point is that we needed to make a decision on how flexible in terms of scheduling the jobs could be. The initial choice (and consensus) was that normal ‘hourly’ / ‘daily’ / ‘weekly’ / ‘monthly’ would suffice. Complex scheduling like you can do with cron requires that we run our own scheduling daemon (or at least store state information) and that was something i wanted to avoid.
If you write a more complex/flexible system and want to help enhance our jobs system with it, i would love to take a look at it.
Ido, Michael,
I write up a spec for it. Just to get my thoughts on paper. I believe it could become a part of or plugin into the Admin interface. Michael has my email address.
Hi, I’ve also written a scheduler using django that plugs into cron. I’ll check the licence again and upload it to the issues site for people to have a look at.
Cheers,