I'm not sure about saying that a project is a "container for apps", and that a project contains "only" settings and "no database models".
At a basic level, a "project" can be just a settings module, but it may include other things. Apps that are sub-packages within a project are generally not pluggable or re-usable in other projects. Pluggable apps that are developed along side a project can and should ideally be in their own repo, but definitely should have their own top level namespace. A project should only "contain" apps that are tightly coupled to the project and/or each other. In this case the use of apps is more to to make navigating a large code base easier, than to facilitate re-use and the creation of pluggable apps. A "project" can also be an "app" and define database models. You just add your "project" to `INSTALLED_APPS`. I often find it convenient for the "project" to also be the main "app". It seems redundant to have two packages, one for the "project" and one for the "app" when they would both logically derive their name from the site. To avoid a top level namespace conflict, I have often seen generic top level package name like `project` or `djangosite`, which make it difficult to then install one site's code as a dependency for another site. Or we end up needlessly repeating the name and having the app as a sub-package (e.g. `foo.foo`). The best options if they are to remain separate seems to be to have a generic sub-package for the project (e.g. `foo.project`) or app (e.g. `foo.base` or `foo.core` or `foo.main`), which allows `foo` to be more easily used as a dependency in another project. The former seems a little counter intuitive, as one might assume that a project is a container for apps (though it is not always and doesn't have to be). The latter is problematic because "base", "core" and "main" are not very good app names. In that case, you'd likely want to set the app label for your models and the verbose name for your app config to "foo" anyway, so you might as well just make `foo` your app as well as being your project. The things most likely to be confusing when treating a project as an app are: 1) The project's root URLconf and the app's URLconf. An app's URLconf doesn't normally include URLconfs from other apps, but a project's root URLconf does. This confusion could largely be eliminated by changing the name of the default root URLconf in the startproject template and in the docs to `root_urls.py`. This makes it clear what's what, and would allow the app URLs to be used more easily in other projects. 2) Project `TEMPLATE_DIRS` vs the `templates` directory in an app. Although to be fair, I've seen many developers struggle just as much (if not more) with where to save and where to find templates when the project and main app are completely separate. It can take a while for newcomers to understand the difference, and then they often remain unsure of where they should save a new template and where they should look to find a template they need to edit. I think this problem would be reduced by having the project also be the main app, and for its `templates` directory to be `TEMPLATE_DIRS[0]`. Ancillary apps would still have their own `templates` directories, but for the most part people would only need to look in one place to edit a template for the project, and they would be less likely to save a new template in the wrong place. When used as a dependency in another project, all the templates would be available (not only app templates), but they would no longer be in `TEMPLATES[0]` so the other project could easily override anything. With separate projects and apps, the other project might not have access to all the templates, unless they explicitly add the first project to `TEMPLATE_DIRS`. Cheers. Tai. On Thursday, November 19, 2015 at 8:54:40 PM UTC+11, guettli wrote: > > I created a ticket to find a better definition of "Project" vs "App" > > https://code.djangoproject.com/ticket/25748 > > I am happy since Tim Graham accepted it. > > Here are the current docs: > https://docs.djangoproject.com/en/1.8/ref/applications/#projects-and-applications > > Here is my view of Project" vs "App". It would be nice to find a consensus > and update the docs. > > Project > ====== > A project is a container for apps. > It contains only settings, no database models. > Since it contains no database models it does not contain database schema > migrations. > It can contain migrations which fill a database with project specific data. > It is common that there is only one production installation of one project. > It is common to have several stages (dev, test, prod) for one project. > A project might contain a sitecustomize.py > > App > === > An app can have models, views and code. > It should be re-usable. > An app can depend on other apps. > It must not depend on a project. > An app can contain a settings.py for testing, but it contains no settings > on its own. > It should have instructions which settings are needed to get the app > running in a project. > A app must not contain a sitecustomize.py. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/03dc159c-f8ee-4ab4-84a5-0c69cb51c015%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
