p15693087
/
django
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Updated a few doc paragraphs following the app-loading refactor.

This commit is contained in:
Aymeric Augustin 2013-12-24 16:28:31 +01:00
parent f326720a73
commit 9b8192ce51
3 changed files with 17 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
docs/internals/contributing/writing-code/unit-tests.txt
View File

@ -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 ``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. 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``. 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 To run tests for just one contrib app (e.g. ``auth``), use the same

16
docs/intro/reusable-apps.txt
View File

@ -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 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 special file ``__init__.py``, even if this file is empty.
A Django *app* is just a Python package that is specifically intended for A Django *application* is just a Python package that is specifically
use in a Django project. An app may also use common Django conventions, intended for use in a Django project. An application may use common Django
such as having a ``models.py`` file. conventions, such as having ``models``, ``tests``, ``urls``, and ``views``
submodules.
Later on we use the term *packaging* to describe the process of making a 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 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 This helps others looking for Django apps identify your app as Django
specific. specific.
The application names (that is, the final dotted part of the Application labels (that is, the final part of the dotted path to
path to the module containing ``models.py``) defined in application packages) *must* be unique in :setting:`INSTALLED_APPS`.
:setting:`INSTALLED_APPS` *must* be unique. Avoid using the Avoid using the same label as any of the Django :doc:`contrib packages
same name as any of the Django :doc:`contrib packages </ref/contrib/index>`, for example ``auth``, ``admin``, or
</ref/contrib/index>`, for example ``auth``, ``admin`` or
``messages``. ``messages``.
2. Move the ``polls`` directory into the ``django-polls`` directory. 2. Move the ``polls`` directory into the ``django-polls`` directory.

19
docs/ref/settings.txt
View File

@ -1285,18 +1285,17 @@ INSTALLED_APPS
Default: ``()`` (Empty tuple) Default: ``()`` (Empty tuple)
A tuple of strings designating all applications that are enabled in this Django A tuple of strings designating all applications that are enabled in this
installation. Each string should be a full Python path to a Python package that Django installation. Each string should be a full Python path to an
contains a Django application, as created by :djadmin:`django-admin.py startapp application configuration class or to a Python package containing a
<startapp>`. 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 Application labels (that is, the final part of the dotted path to
path to the module containing ``models.py``) defined in application packages) *must* be unique in :setting:`INSTALLED_APPS`.
:setting:`INSTALLED_APPS` *must* be unique. For example, you can't For example, you can't include both ``django.contrib.auth`` and
include both ``django.contrib.auth`` and ``myproject.auth`` in ``myproject.auth``.
INSTALLED_APPS.
.. setting:: INTERNAL_IPS .. setting:: INTERNAL_IPS