I found myself doing several of these things over and over when creating a new Django project, so I made a script that wraps the django-admin.py startproject command. Some of these tips I don't quite understand, like creating a custom authentication backend (I've only had to do this once), and creating global template context processor and middleware files. I prefer to keep those bundled individually with the app that uses it. Also, not all of my apps use forms, so why would I make a forms.py for each app?<p>My package is on github here: <a href="http://github.com/dziegler/django-create-project/tree/master" rel="nofollow">http://github.com/dziegler/django-create-project/tree/master</a><p>There's not much documentation because I wasn't really expecting anyone but myself to use it, but basically once it's installed, it'll install a binary file in your path. So instead of<p><pre><code> django-admin.py startproject project_name
</code></pre>
you would do<p><pre><code> create_project project_name
</code></pre>
It'll auto-create your wsgi handler, an apps, templates, static/css, static/js, static/images directories, create a localsettings file, and update your settings. It also automatically installs some common django apps I like to use, like django-command-extensions, django-debug-toolbar, django-css, and clevercss. Like I said, I wasn't really planning on other people finding this valuable and using it, so some of these options are customized to my preferences and you'd probably have to hack it a little bit, but maybe someone here will find it helpful.<p>There's also <a href="http://bitbucket.org/neithere/django-harness/src/" rel="nofollow">http://bitbucket.org/neithere/django-harness/src/</a> which I think might do some similar things, but I found out about it after I already rolled my own thing which works pretty well for me.
Creating a single project wide middleware / context processor file doesn't make sense - each application should provide specific functionality to the project don't group it into a single middleware or context processor.<p>Look at the django.contrib applications. They are perfect examples of how you should structure your apps. The authentication middleware is in django.contrib.auth. etc.<p>If you are automatically deleting models.py, views.py, forms.py your doing it all wrong - rarely should an application get large enough to require these changes to application structure in django.<p>Again django.contrib.admin is the only application that has a views/ directory because it has so many permutations to make generic functionality available to <i>most</i> users.<p>One thing I would like to add is that I think django-admin.py for projects should create the templates directory and static directory when starting a project. It should also generate forms.py, urls.py (not mentioned in the article) and a templates directory for apps.
> Delete models.py and create a models folder
> Delete views.py and create a views folder.<p>I think these are a sign that your applications are too big. I'm biased, but I would use <a href="http://chris-lamb.co.uk/projects/django-lint/" rel="nofollow">http://chris-lamb.co.uk/projects/django-lint/</a> over whilst fleshing out the models (which reports on exactly this issue).
I don't understand why most developers would use a custom auth system. Django's auth system worked fine for me... I just added a UserProfile model to supplement with more fields.<p>Trying to turn Django development into a cookie cutter process seems silly.<p>Do it your own way. Learn it. Understand it. Django is a magical and powerful beast that can be used in many wonderful ways.