Skip to main content

Django Project Setup Conveniences

Whenever I start a new Django project, there are several common steps that I to help standardize my setups.

In settings.py...

I define a PROJECT_ROOT variable which contains the path to the project directory. 

This is useful for various settings in the setup.py:
import sys, os
PROJECT_ROOT = os.path.dirname(__file__)

I set my MEDIA_ROOT to be a path relative to the PROJECT_ROOT.  
Of course, I will need to create this directory on the filesystem. 
MEDIA_ROOT = os.path.join(PROJECT_ROOT, '..','htdocs','media').replace('\\','/') + '/'

And I set a relative TEMPLATE_DIRS path.  I will need to make this directory as well.
TEMPLATE_DIRS = (
    os.path.join(os.path.dirname(__file__), 'templates').replace('\\','/'),
)

Sometimes I add extra directories to the path so I can store specific packages within the project directory. (I might use this if I want to keep all related modules together).
sys.path.insert(0, os.path.join(PROJECT_DIR, "contrib"))
sys.path.insert(0, os.path.join(PROJECT_DIR, "src"))

I generally like to put admin media in the following location:
ADMIN_MEDIA_PREFIX = '/media/admin/'

Almost all the time, I install the following modules in INSTALLED_APPS:
'south', # django-south
'django_extensions', # django-command-extensions

In urls.py...


If I want to use the Django debug server, I'll set this near the top:
from django.conf import settings
urlpatterns = patterns('',)
if settings.DEBUG:
    urlpatterns = patterns('',
        (r'^media/(?P<path>.*)$', 'django.views.static.serve',
                   {'document_root': settings.MEDIA_ROOT}),
    )


Comments

Popular posts from this blog

Django: Using Caching to Track Online Users

Recently I wanted a simple solution to track whether a user is online on a given Django site.  The definition of "online" on a site is kind of ambiguous, so I'll define that a user is considered to be online if they have made any request to the site in the last five minutes. I found that one approach is to use Django's caching framework to track when a user last accessed the site.  For example, upon each request, I can have a middleware set the current time as a cache value associated with a given user.  This allows us to store some basic information about logged-in user's online state without having to hit the database on each request and easily retrieve it by accessing the cache. My approach below.  Comments welcome. In settings.py: # add the middleware that you are about to create to settings MIDDLEWARE_CLASSES = ( .... 'middleware.activeuser_middleware.ActiveUserMiddleware' , .... ) # Setup caching per Django docs. In actuality, you

Django Models Mixins

One thing I've been experimenting with is model Mixins.  For example, the aim is to create small abstract classes that are each focused around a particular function.  These abstract classes can then be added to arbitrary models to apply those functions to models as desired. For example, say I define a RatingsFields abstract class and a TrackingFields abstract class.  These abstract classes can be mixed into any other model that we wish to add rating or tracking functionality to. core/mixins.py from djangoratings.fields import RatingField # 3rd party module class RatingFields(models.Model): rating = RatingField( range =5) # 5 possible rating values, 1-5 class Meta: abstract = True class TrackingFields(models.Model): deleted_on = models.DateTimeField(blank= True , null= True ) created = models.DateTimeField(auto_now_add= True ) modified = models.DateTimeField(auto_now= True ) class Meta: abstract = True

Docker: Run as non root user

It's good practice to run processes within a container as a non-root user with restricted permissions.  Even though containers are isolated from the host operating system, they do share the same kernel as the host. Also, processes within a container should be prevented from writing to where they shouldn't be allowed to as extra protection against exploitation. Running a Docker process as a non-root user has been a Docker feature as of version 1.10. To run a Docker process as a non-root user, permissions need to be accounted for meticulously.  This permission adjustment needs to be done when building a Dockerfile. You need to be aware of where in the filesystem your app might write to, and adjust the permissions accordingly.  Since everything in a container is considered disposable, the container process really shouldn't be writing to too many locations once build. Here is an annotated example of how you might create a Dockerfile where the process that runs within runs a