Is it typical to have more than a dozen django applications in your project root for medium-high scale sites? Does it not feel bloated?

Question

I was looking at the INSTALLED_APPS of django-mingus:

INSTALLED_APPS = (
  'django.contrib.auth',
  'django.contrib.contenttypes',
  'django.contrib.sessions',
  'django.contrib.sites',
  'django.contrib.admin',
  'django.contrib.sitemaps',
  'django.contrib.flatpages',
  'django.contrib.redirects',

  'django_extensions',
  'tagging',
  'djangodblog',
  'disqus',
  'basic.inlines',
  'basic.blog',
  'basic.bookmarks',
  'basic.media',
  'oembed',
  'flatblocks',
  'dbtemplates',
  'navbar',
  'sorl.thumbnail',
  'template_utils',
  'django_proxy',

  'django_markup',
  'google_analytics',
  'robots',
  'basic.elsewhere',
  'compressor',
  'contact_form',
  'honeypot',
  'sugar',
  'quoteme',
  'mingus.core',
  'debug_toolbar',

  'django_twitter',
  'django_bitly',
  'staticfiles',
  'tinymce',
  'django_wysiwyg',
  'cropper',
  'memcache_status',
  'request',
)

This does feel somewhat bloated. But I assume this really isn't as bad as it looks, because django only uses what is requested, in that it doesn't load every application per request, but only if it's called? If not, can someone demystify the process?

Answer 1

I think it's quite common to find a lot of apps in your INSTALLED_APPS. To keep some system in your package/directory structure I think it's recommendable to have your apps inside an apps folder within your project root, while keeping other third party apps, that you do not touch somewhere else on your PYTHONPATH. I think it's very recommendable to use something like PIP and virtualenv to keep track of your apps and organize them. Here you can read another article about a useful directory structure for django projects.

If an app is in your INSTALLED_APPS django will always load its models on startup and populate its APP_CACHE with these classes, but I think this is an overhead you can ignore if you are dealing with conventional apps...

EDIT: Also consider that apps vary a lot in complexity, eg. something like tinymce mainly just provides a widget and some views, but no model, so if it is not used it just adds a few urls to the urlresolver and thats it...

Answer 2

Well, Mingus is specifically a project aimed at demonstrating the use of multiple reusable components, so it's not surprising it uses quite a few of them.

A dozen doesn't sound too bloated, to be honest - I've definitely done sites with more. But in any case, you shouldn't think in terms of requests: Django, or rather mod_wsgi, doesn't start up a stack for each request. Rather, Apache manages processes dynamically, and they load their required code on startup, and the process persists for many requests. This is pretty efficient.

Answer 3

Obviously some of these are 3rd party, and dealing with them by sequestering them in /apps (or even in subdirectories of that, if there are very many) is a good solution for keeping your directory structure sane, as lazerscience points out.

As for your own apps, this is a great question that comes up in #django twice a day or so, and I'd love to see a synthesis of the range of viewpoints.

When I am deciding whether or not to make a separate app, I generally ask myself: Will this new app have models that are a completely different type of knowledge than the apps that came before it? If one app is about people (say, authors) and another is about material possessions (say, books) - it makes sense to separate them. Does 'chapter' need its own app? Clearly not.

I know other developers who focus more on the views that an app has - they ask themselves, "how many top-level terms will I have in my dispatcher?" and go from there. I think this is also a good approach in many cases, but for many projects, some 90% of the models and views will be primarily or exclusively associated with 10% of the top-level URL terms.

As a general matter, having a boatload of apps isn't bad per se. It only becomes bad when it becomes an organizational problem for your group.