[Answered ]-In Django (v1.6.5), what's the best practice for location of Templates, Static files?

Like all frameworks, django offers great benefits if you follow some guidelines (and give up some control). The trick is to know what these guidelines are.

For templates:

1. If the template is not tied to a particular application, put it in a templates directory at the root of your project. Add the full path to this directory to TEMPLATE_DIRS.

2. All other templates should go in a directory called templates inside your application directory. So if you application is called myapp, templates for myapp will go in myapp/templates/

For static files:

1. For files related to specific applications, inside your application directory create a directory called static, then inside it a directory with the name of your application. So, if your application is called myapp, you would have myapp/static/myapp. Place all your static content for this application here; for example myapp/static/myapp/js/funky.js.

2. For static files that are generic, create a directory called assets (or static) in the root directory of your project. Add the full path to this directory to STATICFILES_DIRS.

By default, django will search all applications listed in INSTALLED_APPS, and add any templates and static directories to its search path for files. This is how, by default, the admin works without you having to configure anything.

If you chose to place your templates and static files in some other location, only then do you need to modify the TEMPLATE_DIRS and STATICFILES_DIRS settings. If all your templates and static assets are tied to applications, just creating the directories as mentioned above makes everything work.

If you are wondering why you need to create another directory under myapp/static/ to store your static files, this is more for portability. The collectstatic command is a simply “copy and replace” utility. It will overwrite all files in the STATIC_DIR location. This means that if two applications have some static file with the same name, they will be overwritten without warning. Adding a subdirectory keeps your application’s static assets from being overwritten, because the exact path will be created.

Suppose you have two applications, app1 and app2, and both have a file named style.css in their respected directories:

• app1/static/css/style.css
• app2/static/css/style.css

When you run collectstatic, you’ll end up with the following (assuming static is the name of your STATIC_DIR setting):

• static/css/style.css

This may be the style.css from app1 or app2, the other cannot be determined (its actually based on the INSTALLED_APPS order). To prevent this, if you have:

• app1/static/app1/css/style.css
• app2/static/app2/css/style.css

Now, you’ll end up with:

• static/app1/css/style.css
• static/app2/css/style.css

Both files will be preserved.

You also shouldn’t put your code in your virtual environment directory. The virtual environment is not part of your source code, and placing your project in the same directory may cause problems later.

Create a single directory for your environments – I call mine envs (creative, I know). Create all your environments in this directory. Once you activate the environment, you can work in any directory in your system and your shell will be configured for that environment’s Python.

Finally for the best, accurate, most up-to-date information – always refer to the django manual and the tutorial. Almost all other resources (even the often suggested djangobook.com) are outdated.