* 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.
Comments
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.