Confusion about django app's name

Question

I learned Django following django book and the document. In the django book exmaple, the project is called mysite and there's an app called book inside this project. So in this case, the app is called "book". I've no problem with it.

My confusion arises in front of reusable apps. Reusable apps usually reside outside the project. For example, django-registration only has an independent folder "registration". So what's its app name? "Registration", right?

If that's the case, isn't there some inconsistency regarding the app naming? In the first case, app name seems to be a folder name (or sub package name) under the project while in the 2nd case, the app name is the top package name.

I know most of you will say "Why are you obssessed with app name? Just make sure the package structure is correct and django can run without problems." Yes, in most case, app name is nothing but a name. Except in one occasion: specify AUTH_PROFILE_MODULE. As the document explains,

To indicate that this model is the user profile model for a given site, fill in the setting AUTH_PROFILE_MODULE with a string consisting of the following items, separated by a dot:

1. The name of the application (case sensitive) in which the user profile model is defined (in other words, the name which was passed to manage.py startapp to create the application).
2. The name of the model (not case sensitive) class.

If I have a model as a user profile in a resuable package, I have to know the app name to correctly specify AUTH_PROFILE_MODULE.

Does django use certain path searching order to decide the app name?

Answer 1

When you deploy and app as a standalone package, it is just another Python package, which happens to implement Django views, templates, template tags, etc. Therefore, Django's search path is the Python search path itself. This is why people say "Just make sure the package structure is correct and django can run without problems."

Obviously, if the package name conflicts with someone else's package, you are going to get problems...

Answer 2

The name of the app is the name of the directory, capitalization and all, unless you go to the extra work to change the name in the appropriate __init__.py file. Django apps are, after all, just Python modules, and all the same rules apply.

If you ever see an app or module name with different capitalization or other modifications, that doesn't reflect the actual app or module name. Instead, what you're seeing is the result of some "pretty-printing" that the Django admin app is known to do in some cases. This is for display only.

Answer 3

My confusion arises in front of reusable apps. Reusable apps usually reside outside the project. For example, django-registration only has an independent folder "registration". So what's its app name? "Registration", right?

django-registration is the project name. The application name is registration:

• in application list you are using the application name only: registration
• in other places you will use import registration

If that's the case, isn't there some inconsistency regarding the app naming? In the first case, app name seems to be a folder name (or sub package name) under the project while in the 2nd case, the app name is the top package name.

Think of the project as a simple collection of applications: you could store the apps as subfolders, or place them in a separate folder (that must be included in PYTHONPATH). In both cases the application name is the same.

Update

manage.py adds to the PYTHONPATH both the current folder (so you could use import app.module) and the parent folder (so you can use project.settings and project.urls). So, if you can configure Pydev to add the project folder to the PYTHONPATH, then you could import the apps as app.module, independent of the project name.

Answer 4

An app name is just the name of the Python module. Nothing more.

A python module name is the case name of the root folder of the module, that must contains an init.py file.

If you want to know what this name is, go to your site-packages folder and look for your module.