
Django Best Practices - rs
http://lincolnloop.com/django-best-practices/
======
zentrus
I have been using Django for about 6 months now. Previously, I had been
working on PHP and Rails apps. I have been looking hard for some good best
practices for Django. There are some things I really like about Django. I like
it's readability and I like that new web developers can get up to speed rather
quickly. There is one area that I really wish were better though. It is
unfathomable to me that the norm (and best practice too apparently) is to cram
pounds of code into single files (views.py, models.py, etc). Now sure, it's
Python. You can break it up. But the documentation and also what you see in
Django projects perpetuates this insanity. To break up your models, you must
add additional glue code to each and every model (app_label) and if your app
is large you _will_ run into circular import issues. This is just not
practical for medium to large projects. The best practice is to break up your
project into applications. Yes, that does help some but you still are going to
want to break up an app's model, view, etc into multiple files. Isn't this
common sense? This and other areas of Django often makes me wonder: Why does
Django make it easy to do the wrong things and hard to do the right thing?

------
smackay
It is good to see this but it is also an indictment against Django that there
is no one, true way to get it all set up. Since everything is a python module
it really does not matter how everything is configured, only that it can be
found somewhere on the path, however this causes a great deal of confusion
when getting started that leads to a lot of frustation until the module penny
drops.

~~~
ubercore
You see it as an indictment, I see it as a strength. It's a very pythonic way
to handle things, and while I was confused by a lot of deployment options when
first learning Django, it was only because it was also my introduction to
Python. I'd venture that anyone with decent Python experience will have no
trouble with Django.

~~~
john2x
> It's a very pythonic way to handle things

"There should be one-- and preferably only one --obvious way to do it. "

~~~
ubercore
Although I take issue with trotting out single lines out of context, I'd say
that this is in line with that. The "one -- preferably only one -- obvious way
to do it" is to make everything a module. The confusion stems from not knowing
how to deal with Python modules, not from anything Django is doing. If you
know Python, you know how Django handles things. There's no (or, very little)
magic involved.

~~~
mcdonc
this ^^

------
earle
[http://blog.zacharyvoase.com/2010/02/03/django-project-
conve...](http://blog.zacharyvoase.com/2010/02/03/django-project-conventions/)

Is much more complete IMHO

~~~
Pewpewarrows
In some ways. In other ways it's very lacking:

* Having everything live within the virtualenv directory is extremely dangerous, especially if you ever need to rebuild the ENV. The virtualenv directory should be completely expendable, I would never recommend storing a single critical file in there.

* Sock/PID file permissions are notoriously a pain in the ass, so I tend not to keep them in directories next to project files with having to muck around with proper write permissions. Put them where they belong, in someplace like /var/run

* Since Django now makes the distinction between media and static files, it'd be cleaner to name your js/css/img containing directory "static"

* etcs and settings directories should be combined, with sub-directories that are also python modules. I prefer to call it conf. That way I can reference it as conf.common.settings, conf.staging.settings, etc. Within the common/ and staging/ folders (and others) are also nginx, supervisord, and whatever other config files I need, which are now variable based on the environment.

* urls.py should also end up being in that conf/ module, seeing as you'll need different patterns in development to serve static files, amongst other things.

* The root of your directory that's tracked by version control should not have an __init__.py in it. Throw the PROJECT_ROOT in its own directory and keep files like README, setup.py, etc outside of it, to be more consistent with standardized python packaging.

* When you're deploying to production, keep a directory structure as follows: releases/, logs/, uploads/, static/.

* Releases should contain the past few versions of the site, along with a "current" and "previous" symlink. Serve out of current, which allows you to instantly roll-back to the previous working version should something break.

* You never want to serve raw files out of the innards of your project directory. That's where the outside static/ comes in. This also allows you to rsync it separately from your project, and put it as a release step after gathering the various files needed, as well as concatenating, minifying, and versioning them (for far future Expires headers).

Edit: For the curious I'm releasing a project later this fall called
Prometheus, which includes all the best practices scattered from around the
internet, and is essentially a super beefed-up "startproject", but with a lot
more features that can't be attained just from git cloning someone else's
skeleton Django project directory.

------
Halienja
Django devs should bookmark this
<https://code.djangoproject.com/wiki/DjangoResources>

------
ndreas
This is nice. I've been wanting to dabble a bit in Django, but I find it a bit
hard to find basic information like this, for example, how to decide when
creating a separate app inside a project is better than putting everything in
a single app.

It definitely helps to have conventions to follow while you're learning, until
you become proficient enough to break those conventions.

~~~
huxley
You might find James Bennett's book "Practical Django Projects" helpful:

<http://www.apress.com/open-source/python/9781430219385>

[https://bitbucket.org/ubernostrum/practical-django-
projects/...](https://bitbucket.org/ubernostrum/practical-django-projects/src)

It talks about Django's apps focus and tries to get one out of the habit of
"dumping it all in one app in the project".

Eric Holscher wrote an article about Reusable App conventions:

<http://ericholscher.com/projects/django-conventions/app/>

