[Django]-Large Django application layout

by

33👍

✅

The best way that I have found to go about this is to create applications and then a project to glue them together. Most of my projects have similar apps which are included in each. Emails, notes, action reminders, user auth, etc. My preferred layout is like so:

  • project/
    • settings.py
    • urls.py
    • views.py
    • …
  • apps/
    • emails/
      • urls.py
      • views.py
      • …
    • notes/
      • urls.py
      • views.py
      • …
    • …

apps:

Each of the “apps” stands on its own, and other than a settings.py, does not rely on the project itself (though it can rely on other apps). One of the apps, is the user authentication and management. It has all of the URLs for accomplishing its tasks in apps/auth/urls.py. All of its templates are in apps/auth/templates/auth/. All of its functionality is self-contained, so that when I need to tweak something, I know where to go.

project:

The project/ contains all of the glue required to put these individual apps together into the final project. In my case, I made use heavy of settings.INSTALLED_APPS in project/ to discern which views from the apps were available to me. This way, if I take apps.notes out of my INSTALLED_APPS, everything still works wonderfully, just with no notes.

Maintenance:

This layout/methodology/plan also has long-term positive ramifications. You can re-use any of the apps later on, with almost no work. You can test the system from the bottom up, ensuring that each of the apps works as intended before being integrated into the whole, helping you find/fix bugs quicker. You can implement a new feature without rolling it out to existing instances of the application (if it isn’t in INSTALLED_APPS, they can’t see it).

I’m sure there are better documented ways of laying out a project, and more widely used ways, but this is the one which has worked best for me so far.

👤Jack M.

4👍

You should take a look at :

  • Django generic relations
  • Django reusable apps best practices if you want to re-use
  • GIT or any other CVS (git is great for maintaining + deployment)
  • Fabric if you need automated deployments/updates

I usually use this project structure :

  • /djangoproject
    • /apps
      • /main # the main code
      • /static # each sub app can serve statics
      • /app1
      • /static # each sub app can serve statics
      • /app2…
    • /scripts # manage.py, wsgi, apache.conf, fabfile.py…
    • /core # your libraries …
    • settings.py
    • local_settings.py

Each app in /apps have an urls.py thats autoincluded in the main urls.py. And each app can be a git submodule (or svn external)

Also, using git, you can work on different parallels branches (master/dev/customerA/customerB…) and merge updates.

Creating real reusable is not so easy with django.

👤jujule

4👍

You can extract the common functionality into a separate module and make your apps depend on it:

  • my_portal
  • auth_module
  • profiles_module
  • application1 (depends on auth_module)
  • application2 (depends on auth_module and profiles_module)

I think the fact that a ‘classical’ Django project appear to ‘contain’ the apps it’s using prevent you from seeing the picture – in fact, it’s not necessary. For a project where you’re going to have some sort of pluggable modules I’d suggest organizing the apps as eggs and using zc.buildout+djangorecipe to manage everything.

This way you’ll be able to keep your modules in a flat one-level structure. Eggs have the ability to specify dependencies, so if you install application1 (see above), auth_module will be installed automatically.

Also it’ll be easy to have different configurations deployed to different servers. Suppose, you have server1 which has application1 installed and server2 which has both application1 and application2 installed – you can just have two configs:

server1.cfg:

[buildout]
extends = base_deployment.cfg
eggs += application1

server2.cfg:

[buildout]
extends = base_seployment.cfg
eggs += application1
        application2

djangorecipe also allows you to specify different settings files for each buildout config so you’ll be able to add the necessary bits to the main project’s urls and installed apps settings.

Not to mention, you can also have a separate config for development configuration (with debug=True and Django Debug Toolbar installed, for example).

👤Sergey

Leave a comment