Django Best Practices(lincolnloop.com)
lincolnloop.com
Django Best Practices
http://lincolnloop.com/django-best-practices/
6 comments
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?
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.
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.
It is a strength, without a doubt, but it takes a little time to realise this (hence the myriad of blog posts discussing different possibly ways of laying out projects). Django was also my first intro to Python so the simplicity (and elegance) of the module approach was lost on me as I grappled with finding my way across the vast Django landscape.
> It's a very pythonic way to handle things
"There should be one-- and preferably only one --obvious way to do it. "
"There should be one-- and preferably only one --obvious way to do it. "
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.
this ^^
http://blog.zacharyvoase.com/2010/02/03/django-project-conve...
Is much more complete IMHO
Is much more complete IMHO
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.
* 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.
Django devs should bookmark this https://code.djangoproject.com/wiki/DjangoResources
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.
It definitely helps to have conventions to follow while you're learning, until you become proficient enough to break those conventions.
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/...
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/
http://www.apress.com/open-source/python/9781430219385
https://bitbucket.org/ubernostrum/practical-django-projects/...
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/