mirror of https://github.com/django/django.git
Used :envvar: role and .. envvar:: directive in various docs.
This commit is contained in:
parent
feb91dbda1
commit
fbdb032de2
|
@ -2,12 +2,12 @@
|
|||
FAQ: Using Django
|
||||
=================
|
||||
|
||||
Why do I get an error about importing DJANGO_SETTINGS_MODULE?
|
||||
=============================================================
|
||||
Why do I get an error about importing :envvar:`DJANGO_SETTINGS_MODULE`?
|
||||
=======================================================================
|
||||
|
||||
Make sure that:
|
||||
|
||||
* The environment variable DJANGO_SETTINGS_MODULE is set to a
|
||||
* The environment variable :envvar:`DJANGO_SETTINGS_MODULE` is set to a
|
||||
fully-qualified Python module (i.e. "mysite.settings").
|
||||
|
||||
* Said module is on ``sys.path`` (``import mysite.settings`` should work).
|
||||
|
|
|
@ -77,7 +77,7 @@ The Django-specific options here are:
|
|||
path -- i.e., the directory containing the ``mysite`` package.
|
||||
* ``module``: The WSGI module to use -- probably the ``mysite.wsgi`` module
|
||||
that :djadmin:`startproject` creates.
|
||||
* ``env``: Should probably contain at least ``DJANGO_SETTINGS_MODULE``.
|
||||
* ``env``: Should probably contain at least :envvar:`DJANGO_SETTINGS_MODULE`.
|
||||
* ``home``: Optional path to your project virtualenv.
|
||||
|
||||
Example ini configuration file::
|
||||
|
|
|
@ -283,8 +283,8 @@ at the top level (i.e. evaluated when the module is imported). The explanation
|
|||
for this is as follows:
|
||||
|
||||
Manual configuration of settings (i.e. not relying on the
|
||||
``DJANGO_SETTINGS_MODULE`` environment variable) is allowed and possible as
|
||||
follows::
|
||||
:envvar:`DJANGO_SETTINGS_MODULE` environment variable) is allowed and possible
|
||||
as follows::
|
||||
|
||||
from django.conf import settings
|
||||
|
||||
|
|
|
@ -105,8 +105,8 @@ The remainder of this documentation shows commands for running tests without
|
|||
``tox``, however, any option passed to ``runtests.py`` can also be passed to
|
||||
``tox`` by prefixing the argument list with ``--``, as above.
|
||||
|
||||
Tox also respects the ``DJANGO_SETTINGS_MODULE`` environment variable, if set.
|
||||
For example, the following is equivalent to the command above:
|
||||
Tox also respects the :envvar:`DJANGO_SETTINGS_MODULE` environment variable, if
|
||||
set. For example, the following is equivalent to the command above:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
@ -156,7 +156,7 @@ those for ``contrib.postgres``, are specific to a particular database backend
|
|||
and will be skipped if run with a different backend.
|
||||
|
||||
To run the tests with different settings, ensure that the module is on your
|
||||
``PYTHONPATH`` and pass the module with ``--settings``.
|
||||
:envvar:`PYTHONPATH` and pass the module with ``--settings``.
|
||||
|
||||
The :setting:`DATABASES` setting in any test settings module needs to define
|
||||
two databases:
|
||||
|
@ -495,8 +495,8 @@ test failures. You can adjust this behavior with the ``--parallel`` option:
|
|||
|
||||
$ ./runtests.py basic --parallel=1
|
||||
|
||||
You can also use the ``DJANGO_TEST_PROCESSES`` environment variable for this
|
||||
purpose.
|
||||
You can also use the :envvar:`DJANGO_TEST_PROCESSES` environment variable for
|
||||
this purpose.
|
||||
|
||||
Tips for writing tests
|
||||
======================
|
||||
|
|
|
@ -246,6 +246,10 @@ documentation:
|
|||
* Use :rst:role:`:mimetype:<mimetype>` to refer to a MIME Type unless the value
|
||||
is quoted for a code example.
|
||||
|
||||
* Use :rst:role:`:envvar:<envvar>` to refer to an environment variable. You may
|
||||
also need to define a reference to the documentation for that environment
|
||||
variable using :rst:dir:`.. envvar:: <envvar>`.
|
||||
|
||||
Django-specific markup
|
||||
======================
|
||||
|
||||
|
|
|
@ -378,8 +378,8 @@ API Django gives you. To invoke the Python shell, use this command:
|
|||
$ python manage.py shell
|
||||
|
||||
We're using this instead of simply typing "python", because :file:`manage.py`
|
||||
sets the ``DJANGO_SETTINGS_MODULE`` environment variable, which gives Django
|
||||
the Python import path to your :file:`mysite/settings.py` file.
|
||||
sets the :envvar:`DJANGO_SETTINGS_MODULE` environment variable, which gives
|
||||
Django the Python import path to your :file:`mysite/settings.py` file.
|
||||
|
||||
Once you're in the shell, explore the :doc:`database API </topics/db/queries>`::
|
||||
|
||||
|
|
|
@ -111,7 +111,7 @@ Asynchronous support
|
|||
|
||||
The following checks verify your setup for :doc:`/topics/async`:
|
||||
|
||||
* **async.E001**: You should not set the ``DJANGO_ALLOW_ASYNC_UNSAFE``
|
||||
* **async.E001**: You should not set the :envvar:`DJANGO_ALLOW_ASYNC_UNSAFE`
|
||||
environment variable in deployment. This disables :ref:`async safety
|
||||
protection <async-safety>`.
|
||||
|
||||
|
|
|
@ -32,7 +32,7 @@ features include:
|
|||
in Python using ``ctypes``.
|
||||
* Loosely-coupled to GeoDjango. For example, :class:`GEOSGeometry` objects
|
||||
may be used outside of a Django project/application. In other words,
|
||||
no need to have ``DJANGO_SETTINGS_MODULE`` set or use a database, etc.
|
||||
no need to have :envvar:`DJANGO_SETTINGS_MODULE` set or use a database, etc.
|
||||
* Mutability: :class:`GEOSGeometry` objects may be modified.
|
||||
* Cross-platform and tested; compatible with Windows, Linux, Solaris, and
|
||||
macOS platforms.
|
||||
|
|
|
@ -127,8 +127,8 @@ Activates some additional checks that are only relevant in a deployment setting.
|
|||
You can use this option in your local development environment, but since your
|
||||
local development settings module may not have many of your production settings,
|
||||
you will probably want to point the ``check`` command at a different settings
|
||||
module, either by setting the ``DJANGO_SETTINGS_MODULE`` environment variable,
|
||||
or by passing the ``--settings`` option::
|
||||
module, either by setting the :envvar:`DJANGO_SETTINGS_MODULE` environment
|
||||
variable, or by passing the ``--settings`` option::
|
||||
|
||||
django-admin check --deploy --settings=production_settings
|
||||
|
||||
|
@ -940,8 +940,10 @@ more robust change detection, and a reduction in power usage. Django supports
|
|||
|
||||
.. admonition:: Watchman timeout
|
||||
|
||||
.. envvar:: DJANGO_WATCHMAN_TIMEOUT
|
||||
|
||||
The default timeout of ``Watchman`` client is 5 seconds. You can change it
|
||||
by setting the ``DJANGO_WATCHMAN_TIMEOUT`` environment variable.
|
||||
by setting the :envvar:`DJANGO_WATCHMAN_TIMEOUT` environment variable.
|
||||
|
||||
.. _Watchman: https://facebook.github.io/watchman/
|
||||
.. _pywatchman: https://pypi.org/project/pywatchman/
|
||||
|
@ -1420,13 +1422,15 @@ Enables :ref:`SQL logging <django-db-logger>` for failing tests. If
|
|||
|
||||
.. django-admin-option:: --parallel [N]
|
||||
|
||||
.. envvar:: DJANGO_TEST_PROCESSES
|
||||
|
||||
Runs tests in separate parallel processes. Since modern processors have
|
||||
multiple cores, this allows running tests significantly faster.
|
||||
|
||||
By default ``--parallel`` runs one process per core according to
|
||||
:func:`multiprocessing.cpu_count()`. You can adjust the number of processes
|
||||
either by providing it as the option's value, e.g. ``--parallel=4``, or by
|
||||
setting the ``DJANGO_TEST_PROCESSES`` environment variable.
|
||||
setting the :envvar:`DJANGO_TEST_PROCESSES` environment variable.
|
||||
|
||||
Django distributes test cases — :class:`unittest.TestCase` subclasses — to
|
||||
subprocesses. If there are fewer test cases than configured processes, Django
|
||||
|
@ -1599,6 +1603,8 @@ Example usage::
|
|||
|
||||
.. django-admin:: createsuperuser
|
||||
|
||||
.. envvar:: DJANGO_SUPERUSER_PASSWORD
|
||||
|
||||
This command is only available if Django's :doc:`authentication system
|
||||
</topics/auth/index>` (``django.contrib.auth``) is installed.
|
||||
|
||||
|
@ -1608,9 +1614,9 @@ programmatically generate superuser accounts for your site(s).
|
|||
|
||||
When run interactively, this command will prompt for a password for
|
||||
the new superuser account. When run non-interactively, you can provide
|
||||
a password by setting the ``DJANGO_SUPERUSER_PASSWORD`` environment variable.
|
||||
Otherwise, no password will be set, and the superuser account will not be able
|
||||
to log in until a password has been manually set for it.
|
||||
a password by setting the :envvar:`DJANGO_SUPERUSER_PASSWORD` environment
|
||||
variable. Otherwise, no password will be set, and the superuser account will
|
||||
not be able to log in until a password has been manually set for it.
|
||||
|
||||
In non-interactive mode, the
|
||||
:attr:`~django.contrib.auth.models.CustomUser.USERNAME_FIELD` and required
|
||||
|
@ -1738,7 +1744,7 @@ allows for the following options:
|
|||
.. django-admin-option:: --pythonpath PYTHONPATH
|
||||
|
||||
Adds the given filesystem path to the Python `import search path`_. If this
|
||||
isn't provided, ``django-admin`` will use the ``PYTHONPATH`` environment
|
||||
isn't provided, ``django-admin`` will use the :envvar:`PYTHONPATH` environment
|
||||
variable.
|
||||
|
||||
This option is unnecessary in ``manage.py``, because it takes care of setting
|
||||
|
@ -1754,7 +1760,8 @@ Example usage::
|
|||
|
||||
Specifies the settings module to use. The settings module should be in Python
|
||||
package syntax, e.g. ``mysite.settings``. If this isn't provided,
|
||||
``django-admin`` will use the ``DJANGO_SETTINGS_MODULE`` environment variable.
|
||||
``django-admin`` will use the :envvar:`DJANGO_SETTINGS_MODULE` environment
|
||||
variable.
|
||||
|
||||
This option is unnecessary in ``manage.py``, because it uses
|
||||
``settings.py`` from the current project by default.
|
||||
|
@ -1822,6 +1829,8 @@ Extra niceties
|
|||
Syntax coloring
|
||||
---------------
|
||||
|
||||
.. envvar:: DJANGO_COLORS
|
||||
|
||||
The ``django-admin`` / ``manage.py`` commands will use pretty
|
||||
color-coded output if your terminal supports ANSI-colored output. It
|
||||
won't use the color codes if you're piping the command's output to
|
||||
|
@ -1843,7 +1852,7 @@ ships with three color palettes:
|
|||
|
||||
* ``nocolor``, which disables syntax highlighting.
|
||||
|
||||
You select a palette by setting a ``DJANGO_COLORS`` environment
|
||||
You select a palette by setting a :envvar:`DJANGO_COLORS` environment
|
||||
variable to specify the palette you want to use. For example, to
|
||||
specify the ``light`` palette under a Unix or OS/X BASH shell, you
|
||||
would run the following at a command prompt::
|
||||
|
|
|
@ -321,9 +321,9 @@ and calculated values can be displayed alongside editable fields.
|
|||
Customizable syntax highlighting
|
||||
--------------------------------
|
||||
|
||||
You can now use a ``DJANGO_COLORS`` environment variable to modify or disable
|
||||
the colors used by ``django-admin.py`` to provide :ref:`syntax highlighting
|
||||
<syntax-coloring>`.
|
||||
You can now use a :envvar:`DJANGO_COLORS` environment variable to modify or
|
||||
disable the colors used by ``django-admin.py`` to provide :ref:`syntax
|
||||
highlighting <syntax-coloring>`.
|
||||
|
||||
Syndication feeds as views
|
||||
--------------------------
|
||||
|
|
|
@ -1257,7 +1257,7 @@ needed with the new ``manage.py`` and default project layout.
|
|||
|
||||
This function was never documented or part of the public API, but it was widely
|
||||
recommended for use in setting up a "Django environment" for a user script.
|
||||
These uses should be replaced by setting the ``DJANGO_SETTINGS_MODULE``
|
||||
These uses should be replaced by setting the :envvar:`DJANGO_SETTINGS_MODULE`
|
||||
environment variable or using :func:`django.conf.settings.configure`.
|
||||
|
||||
``django.core.management.execute_manager``
|
||||
|
|
|
@ -58,7 +58,8 @@ Bugfixes
|
|||
|
||||
* Increased the default timeout when using ``Watchman`` to 5 seconds to prevent
|
||||
falling back to ``StatReloader`` on larger projects and made it customizable
|
||||
via the ``DJANGO_WATCHMAN_TIMEOUT`` environment variable (:ticket:`30361`).
|
||||
via the :envvar:`DJANGO_WATCHMAN_TIMEOUT` environment variable
|
||||
(:ticket:`30361`).
|
||||
|
||||
* Fixed a regression in Django 2.2 that caused a crash when migrating
|
||||
permissions for proxy models if the target permissions already existed. For
|
||||
|
|
|
@ -28,7 +28,7 @@ Bugfixes
|
|||
* Fixed a regression in Django 3.0 by restoring the ability to use Django
|
||||
inside Jupyter and other environments that force an async context, by adding
|
||||
an option to disable :ref:`async-safety` mechanism with
|
||||
``DJANGO_ALLOW_ASYNC_UNSAFE`` environment variable (:ticket:`31056`).
|
||||
:envvar:`DJANGO_ALLOW_ASYNC_UNSAFE` environment variable (:ticket:`31056`).
|
||||
|
||||
* Fixed a regression in Django 3.0 where ``RegexPattern``, used by
|
||||
:func:`~django.urls.re_path`, returned positional arguments to be passed to
|
||||
|
|
|
@ -118,6 +118,8 @@ mode if you have asynchronous code in your project.
|
|||
Async safety
|
||||
============
|
||||
|
||||
.. envvar:: DJANGO_ALLOW_ASYNC_UNSAFE
|
||||
|
||||
Certain key parts of Django are not able to operate safely in an async
|
||||
environment, as they have global state that is not coroutine-aware. These parts
|
||||
of Django are classified as "async-unsafe", and are protected from execution in
|
||||
|
@ -144,7 +146,7 @@ if the requirement is forced on you by an external environment, such as in a
|
|||
Jupyter_ notebook. If you are sure there is no chance of the code being run
|
||||
concurrently, and you *absolutely* need to run this sync code from an async
|
||||
context, then you can disable the warning by setting the
|
||||
``DJANGO_ALLOW_ASYNC_UNSAFE`` environment variable to any value.
|
||||
:envvar:`DJANGO_ALLOW_ASYNC_UNSAFE` environment variable to any value.
|
||||
|
||||
.. warning::
|
||||
|
||||
|
|
|
@ -40,10 +40,10 @@ Designating the settings
|
|||
.. envvar:: DJANGO_SETTINGS_MODULE
|
||||
|
||||
When you use Django, you have to tell it which settings you're using. Do this
|
||||
by using an environment variable, ``DJANGO_SETTINGS_MODULE``.
|
||||
by using an environment variable, :envvar:`DJANGO_SETTINGS_MODULE`.
|
||||
|
||||
The value of ``DJANGO_SETTINGS_MODULE`` should be in Python path syntax, e.g.
|
||||
``mysite.settings``. Note that the settings module should be on the
|
||||
The value of :envvar:`DJANGO_SETTINGS_MODULE` should be in Python path syntax,
|
||||
e.g. ``mysite.settings``. Note that the settings module should be on the
|
||||
Python `import search path`_.
|
||||
|
||||
.. _import search path: https://www.diveinto.org/python3/your-first-python-program.html#importsearchpath
|
||||
|
@ -170,10 +170,10 @@ a convention.
|
|||
|
||||
.. _settings-without-django-settings-module:
|
||||
|
||||
Using settings without setting ``DJANGO_SETTINGS_MODULE``
|
||||
=========================================================
|
||||
Using settings without setting :envvar:`DJANGO_SETTINGS_MODULE`
|
||||
===============================================================
|
||||
|
||||
In some cases, you might want to bypass the ``DJANGO_SETTINGS_MODULE``
|
||||
In some cases, you might want to bypass the :envvar:`DJANGO_SETTINGS_MODULE`
|
||||
environment variable. For example, if you're using the template system by
|
||||
itself, you likely don't want to have to set up an environment variable
|
||||
pointing to a settings module.
|
||||
|
@ -234,19 +234,19 @@ defaults, so you must specify a value for every possible setting that might be
|
|||
used in that code you are importing. Check in
|
||||
``django.conf.settings.global_settings`` for the full list.
|
||||
|
||||
Either ``configure()`` or ``DJANGO_SETTINGS_MODULE`` is required
|
||||
----------------------------------------------------------------
|
||||
Either ``configure()`` or :envvar:`DJANGO_SETTINGS_MODULE` is required
|
||||
----------------------------------------------------------------------
|
||||
|
||||
If you're not setting the ``DJANGO_SETTINGS_MODULE`` environment variable, you
|
||||
*must* call ``configure()`` at some point before using any code that reads
|
||||
settings.
|
||||
If you're not setting the :envvar:`DJANGO_SETTINGS_MODULE` environment
|
||||
variable, you *must* call ``configure()`` at some point before using any code
|
||||
that reads settings.
|
||||
|
||||
If you don't set ``DJANGO_SETTINGS_MODULE`` and don't call ``configure()``,
|
||||
Django will raise an ``ImportError`` exception the first time a setting
|
||||
is accessed.
|
||||
If you don't set :envvar:`DJANGO_SETTINGS_MODULE` and don't call
|
||||
``configure()``, Django will raise an ``ImportError`` exception the first time
|
||||
a setting is accessed.
|
||||
|
||||
If you set ``DJANGO_SETTINGS_MODULE``, access settings values somehow, *then*
|
||||
call ``configure()``, Django will raise a ``RuntimeError`` indicating
|
||||
If you set :envvar:`DJANGO_SETTINGS_MODULE`, access settings values somehow,
|
||||
*then* call ``configure()``, Django will raise a ``RuntimeError`` indicating
|
||||
that settings have already been configured. There is a property for this
|
||||
purpose:
|
||||
|
||||
|
@ -262,7 +262,7 @@ Also, it's an error to call ``configure()`` more than once, or to call
|
|||
``configure()`` after any setting has been accessed.
|
||||
|
||||
It boils down to this: Use exactly one of either ``configure()`` or
|
||||
``DJANGO_SETTINGS_MODULE``. Not both, and not neither.
|
||||
:envvar:`DJANGO_SETTINGS_MODULE`. Not both, and not neither.
|
||||
|
||||
Calling ``django.setup()`` is required for "standalone" Django usage
|
||||
--------------------------------------------------------------------
|
||||
|
|
Loading…
Reference in New Issue