Basic configuration and namespacing

Sometimes what is obvious when you're working with multiple apps in a single project becomes less so when you focus on an app on its own. One such thing is namespacing.

Namespacing comes not just from the module-level namespacing, but how the app is named when included in the project. You can name all your views something generic or very detail specific and allow overlapping view or URL names provided the URLs are namespaced.

AppConfig

Django's AppConfig class lets you specify configuration data for your application including the name of your application, i.e. how Django identifies an installed instance of your application, how it is presented to users on a site where it is installed, not to mention letting you set up aspects of your application works at process start up.

At a basic level you should set up an AppConfig class that provides a name and verbose name for your app.

from django.apps import AppConfig
from django.utils.translation.ugettext_lazy as _

class SubscriptionsConfig(AppConfig):
    name = "subscriptions"
    verbose_name = _("Subscriptions")

Note the name isn't translated as this is used programmatically, whereas the verbose name may be presented to end users.

URLs

URL namespacing is easy given that it's something you anyone using your app can add. They just need to add the namespace keyword argument to their url declaration and they can use whatever namespace they want.

The simplest thing to do is provide an application name as an argument for your URLs as an object in your urls.py file and instruct users to include this.

Modified from the docs:

url_patterns = ([
    url(r'^$', views.PlanList.as_view(), name='index'),
    url(r'^(?P<pk>\d+)/$', views.PlanDetail.as_view(), name='detail'),
], 'subscriptions')

Instead of having your end users include your URLs module, they would include the object created above, e.g.

urlpatterns = [
    url(r'^plans/', include(subscriptions.urls.url_patterns)),
]

Avoid using app_namespace as this is deprecated.