

First Things To Do on a New Django Project - alanthonyc
http://djangozen.com/blog/first-things-to-do-on-a-django-project..

======
thomaspaine
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?

My package is on github here: <http://github.com/dziegler/django-create-
project/tree/master>

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

    
    
      django-admin.py startproject project_name
    

you would do

    
    
      create_project project_name
    

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.

There's also <http://bitbucket.org/neithere/django-harness/src/> 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.

~~~
tvon
Interesting, I wrote something similar here:

<http://github.com/tvon/django-gig/tree/master>

Yours is written better... and mine pisses all over the default Django layout
(which I've never been a fan of).

------
jdagostino
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.

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.

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.

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
_most_ users.

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.

------
lamby
> Delete models.py and create a models folder > Delete views.py and create a
> views folder.

I think these are a sign that your applications are too big. I'm biased, but I
would use <http://chris-lamb.co.uk/projects/django-lint/> over whilst fleshing
out the models (which reports on exactly this issue).

------
andrewljohnson
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.

Trying to turn Django development into a cookie cutter process seems silly.

Do it your own way. Learn it. Understand it. Django is a magical and powerful
beast that can be used in many wonderful ways.

~~~
mtrichardson
If it works for you, it works great - if it doesn't, you're kind of screwed.

Where "works for you" the vast majority of the time really just means "the
model fits your needs" (that is, username that fits the validator, non-unique
email addresses, and so forth).

Don't get me wrong, I'm really grateful for contrib.auth, I just find myself
butting heads with it fairly often.

~~~
andrewljohnson
Sure, but that's you. The very vast majority of django devs will find it suits
their purpose. The VERY vast majority of Django projects are small and fast.
Myself, I've done half a dozen projects, one spanning 20 kLoc, and the rest
very small. I've never had a problem with Django auth.

To recommend it as something you should do when you make a Django app is bad
advice, particularly for the beginners, who will just be confused by the extra
steps.

I recommend anyone who isn't familiar with Django simply do the "My First App"
tutorial. After that, the dev will find their own way, and I doubt it will be
much like yours, or mine.

~~~
mtrichardson
He's not recommending creating an alternative to contrib.auth, he's talking
about an auth backend.

[http://docs.djangoproject.com/en/dev/topics/auth/#other-
auth...](http://docs.djangoproject.com/en/dev/topics/auth/#other-
authentication-sources)

I agree that it's an absurd recommendation, however.

