Django: "projects" vs "apps"


I have a fairly complex "product" I'm getting ready to build using Django. I'm going to avoid using the terms "project" and "application" in this context, because I'm not clear on their specific meaning in Django.

Projects can have many apps. Apps can be shared among many projects. Fine.

I'm not reinventing the blog or forum - I don't see any portion of my product being reusable in any context. Intuitively, I would call this one "application." Do I then do all my work in a single "app" folder?

If so... in terms of Django's namespace, my inclination is to use myproduct.myproduct, but of course this isn't allowed (but the application I'm building is my project, and my project is an application!). I'm therefore lead to believe that perhaps I'm supposed to approach Django by building one app per "significant" model, but I don't know where to draw the boundaries in my schema to separate it into apps - I have a lot of models with relatively complex relationships.

I'm hoping there's a common solution to this...

2/2/2011 7:41:49 PM

Accepted Answer

What is to stop you using myproduct.myproduct? What you need to achieve that roughly consists of doing this: startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/
touch myproduct/
touch myproduct/

and so on. Would it help if I said doesn't have to be called Provided you can name, on the python path, a function (usually package.package.views.function_name) it will get handled. Simple as that. All this "project"/"app" stuff is just python packages.

Now, how are you supposed to do it? Or rather, how might I do it? Well, if you create a significant piece of reusable functionality, like say a markup editor, that's when you create a "top level app" which might contain,, etc - all things you might want to import.

Similarly, if you can create something like a blog in a format that is pretty generic across installs, you can wrap it up in an app, with its own template, static content folder etc, and configure an instance of a django project to use that app's content.

There are no hard and fast rules saying you must do this, but it is one of the goals of the framework. The fact that everything, templates included, allows you to include from some common base means your blog should fit snugly into any other setup, simply by looking after its own part.

However, to address your actual concern, yes, nothing says you can't work with the top level project folder. That's what apps do and you can do it if you really want to. I tend not to, however, for several reasons:

  • Django's default setup doesn't do it.
  • Often, I want to create a main app, so I create one, usually called website. However, at a later date I might want to develop original functionality just for this site. With a view to making it removable (whether or not I ever do) I tend to then create a separate directory. This also means I can drop said functionality just by unlinking that package from the config and removing the folder, rather than a complex delete the right urls from a global folder.
  • Very often, even when I want to make something independent, it needs somewhere to live whilst I look after it / make it independent. Basically the above case, but for stuff I do intend to make generic.
  • My top level folder often contains a few other things, including but not limited to wsgi scripts, sql scripts etc.
  • django's management extensions rely on subdirectories. So it makes sense to name packages appropriately.

In short, the reason there is a convention is the same as any other convention - it helps when it comes to others working with your project. If I see I immediately expect code in it to subclass django's field, whereas if I see I might not be so clear on what that means without looking at it.

2/2/2011 7:58:21 PM

Once you graduate from using startproject and startapp, there's nothing to stop you from combining a "project" and "app" in the same Python package. A project is really nothing more than a settings module, and an app is really nothing more than a models module—everything else is optional.

For small sites, it's entirely reasonable to have something like:


Licensed under: CC-BY-SA with attribution
Not affiliated with: Stack Overflow