mirror of https://github.com/django/django.git
Updated a few doc paragraphs following the app-loading refactor.
This commit is contained in:
parent
f326720a73
commit
9b8192ce51
|
@ -222,7 +222,6 @@ Tests for contrib apps go in their respective directories under
|
|||
``django/contrib``, in a ``tests.py`` file. You can split the tests over
|
||||
multiple modules by using a ``tests`` directory in the normal Python way.
|
||||
|
||||
For the tests to be found, a ``models.py`` file must exist, even if it's empty.
|
||||
If you have URLs that need to be mapped, put them in ``tests/urls.py``.
|
||||
|
||||
To run tests for just one contrib app (e.g. ``auth``), use the same
|
||||
|
|
|
@ -42,9 +42,10 @@ projects and ready to publish for others to install and use.
|
|||
bar``. For a directory (like ``polls``) to form a package, it must contain
|
||||
a special file ``__init__.py``, even if this file is empty.
|
||||
|
||||
A Django *app* is just a Python package that is specifically intended for
|
||||
use in a Django project. An app may also use common Django conventions,
|
||||
such as having a ``models.py`` file.
|
||||
A Django *application* is just a Python package that is specifically
|
||||
intended for use in a Django project. An application may use common Django
|
||||
conventions, such as having ``models``, ``tests``, ``urls``, and ``views``
|
||||
submodules.
|
||||
|
||||
Later on we use the term *packaging* to describe the process of making a
|
||||
Python package easy for others to install. It can be a little confusing, we
|
||||
|
@ -128,11 +129,10 @@ this. For a small app like polls, this process isn't too difficult.
|
|||
This helps others looking for Django apps identify your app as Django
|
||||
specific.
|
||||
|
||||
The application names (that is, the final dotted part of the
|
||||
path to the module containing ``models.py``) defined in
|
||||
:setting:`INSTALLED_APPS` *must* be unique. Avoid using the
|
||||
same name as any of the Django :doc:`contrib packages
|
||||
</ref/contrib/index>`, for example ``auth``, ``admin`` or
|
||||
Application labels (that is, the final part of the dotted path to
|
||||
application packages) *must* be unique in :setting:`INSTALLED_APPS`.
|
||||
Avoid using the same label as any of the Django :doc:`contrib packages
|
||||
</ref/contrib/index>`, for example ``auth``, ``admin``, or
|
||||
``messages``.
|
||||
|
||||
2. Move the ``polls`` directory into the ``django-polls`` directory.
|
||||
|
|
|
@ -1285,18 +1285,17 @@ INSTALLED_APPS
|
|||
|
||||
Default: ``()`` (Empty tuple)
|
||||
|
||||
A tuple of strings designating all applications that are enabled in this Django
|
||||
installation. Each string should be a full Python path to a Python package that
|
||||
contains a Django application, as created by :djadmin:`django-admin.py startapp
|
||||
<startapp>`.
|
||||
A tuple of strings designating all applications that are enabled in this
|
||||
Django installation. Each string should be a full Python path to an
|
||||
application configuration class or to a Python package containing a
|
||||
application. :ref:` Learn more about applications </ref/applications>`.
|
||||
|
||||
.. admonition:: App names must be unique
|
||||
.. admonition:: Application labels must be unique
|
||||
|
||||
The application names (that is, the final dotted part of the
|
||||
path to the module containing ``models.py``) defined in
|
||||
:setting:`INSTALLED_APPS` *must* be unique. For example, you can't
|
||||
include both ``django.contrib.auth`` and ``myproject.auth`` in
|
||||
INSTALLED_APPS.
|
||||
Application labels (that is, the final part of the dotted path to
|
||||
application packages) *must* be unique in :setting:`INSTALLED_APPS`.
|
||||
For example, you can't include both ``django.contrib.auth`` and
|
||||
``myproject.auth``.
|
||||
|
||||
.. setting:: INTERNAL_IPS
|
||||
|
||||
|
|
Loading…
Reference in New Issue