2016-01-24 22:26:11 +01:00
|
|
|
|
==================================
|
|
|
|
|
``django-admin`` and ``manage.py``
|
|
|
|
|
==================================
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
``django-admin`` is Django's command-line utility for administrative tasks.
|
2005-08-10 22:24:51 +02:00
|
|
|
|
This document outlines all it can do.
|
|
|
|
|
|
2006-01-11 03:06:27 +01:00
|
|
|
|
In addition, ``manage.py`` is automatically created in each Django project.
|
2015-11-21 14:37:52 +01:00
|
|
|
|
``manage.py`` does the same thing as ``django-admin`` but takes care of a few
|
|
|
|
|
things for you:
|
2006-01-11 03:06:27 +01:00
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* It puts your project's package on ``sys.path``.
|
2006-01-11 03:06:27 +01:00
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* It sets the :envvar:`DJANGO_SETTINGS_MODULE` environment variable so that
|
|
|
|
|
it points to your project's ``settings.py`` file.
|
2006-01-11 03:06:27 +01:00
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
The ``django-admin`` script should be on your system path if you installed
|
2008-08-24 00:25:40 +02:00
|
|
|
|
Django via its ``setup.py`` utility. If it's not on your path, you can find it
|
|
|
|
|
in ``site-packages/django/bin`` within your Python installation. Consider
|
2007-02-10 10:07:54 +01:00
|
|
|
|
symlinking it from some place on your path, such as ``/usr/local/bin``.
|
|
|
|
|
|
2008-08-24 00:25:40 +02:00
|
|
|
|
For Windows users, who do not have symlinking functionality available, you can
|
2014-07-26 13:21:52 +02:00
|
|
|
|
copy ``django-admin.exe`` to a location on your existing path or edit the
|
2008-08-24 00:25:40 +02:00
|
|
|
|
``PATH`` settings (under ``Settings - Control Panel - System - Advanced -
|
|
|
|
|
Environment...``) to point to its installed location.
|
2006-05-02 03:31:56 +02:00
|
|
|
|
|
2006-01-11 03:06:27 +01:00
|
|
|
|
Generally, when working on a single Django project, it's easier to use
|
2014-07-26 13:21:52 +02:00
|
|
|
|
``manage.py`` than ``django-admin``. If you need to switch between multiple
|
|
|
|
|
Django settings files, use ``django-admin`` with
|
2016-01-12 02:59:34 +01:00
|
|
|
|
:envvar:`DJANGO_SETTINGS_MODULE` or the :option:`--settings` command line
|
2013-04-12 12:10:26 +02:00
|
|
|
|
option.
|
2006-01-11 03:06:27 +01:00
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
The command-line examples throughout this document use ``django-admin`` to
|
2015-04-30 17:54:45 +02:00
|
|
|
|
be consistent, but any example can use ``manage.py`` or ``python -m django``
|
|
|
|
|
just as well.
|
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.9
|
|
|
|
|
|
|
|
|
|
``python -m django`` was added.
|
2007-04-09 03:44:26 +02:00
|
|
|
|
|
2005-08-10 22:24:51 +02:00
|
|
|
|
Usage
|
|
|
|
|
=====
|
|
|
|
|
|
2015-02-19 04:19:21 +01:00
|
|
|
|
.. code-block:: console
|
2006-01-11 06:54:13 +01:00
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
$ django-admin <command> [options]
|
2013-12-25 20:54:14 +01:00
|
|
|
|
$ manage.py <command> [options]
|
2015-04-30 17:54:45 +02:00
|
|
|
|
$ python -m django <command> [options]
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2010-10-23 18:37:51 +02:00
|
|
|
|
``command`` should be one of the commands listed in this document.
|
2007-09-09 23:57:59 +02:00
|
|
|
|
``options``, which is optional, should be zero or more of the options available
|
2010-10-23 18:37:51 +02:00
|
|
|
|
for the given command.
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2007-09-09 23:57:59 +02:00
|
|
|
|
Getting runtime help
|
|
|
|
|
--------------------
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2012-02-07 19:46:29 +01:00
|
|
|
|
.. django-admin:: help
|
2008-08-24 00:25:40 +02:00
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
Run ``django-admin help`` to display usage information and a list of the
|
2012-02-07 19:46:29 +01:00
|
|
|
|
commands provided by each application.
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
Run ``django-admin help --commands`` to display a list of all available
|
2012-02-07 19:46:29 +01:00
|
|
|
|
commands.
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
Run ``django-admin help <command>`` to display a description of the given
|
2012-02-07 19:46:29 +01:00
|
|
|
|
command and a list of its available options.
|
2007-09-09 23:57:59 +02:00
|
|
|
|
|
|
|
|
|
App names
|
|
|
|
|
---------
|
|
|
|
|
|
2010-10-23 18:37:51 +02:00
|
|
|
|
Many commands take a list of "app names." An "app name" is the basename of
|
2011-05-29 19:41:04 +02:00
|
|
|
|
the package containing your models. For example, if your :setting:`INSTALLED_APPS`
|
2007-09-09 23:57:59 +02:00
|
|
|
|
contains the string ``'mysite.blog'``, the app name is ``blog``.
|
|
|
|
|
|
|
|
|
|
Determining the version
|
|
|
|
|
-----------------------
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2012-02-07 19:46:29 +01:00
|
|
|
|
.. django-admin:: version
|
2008-08-24 00:25:40 +02:00
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
Run ``django-admin version`` to display the current Django version.
|
2007-09-09 23:57:59 +02:00
|
|
|
|
|
2016-01-12 15:19:07 +01:00
|
|
|
|
The output follows the schema described in :pep:`440`::
|
2007-09-09 23:57:59 +02:00
|
|
|
|
|
2012-02-09 09:37:33 +01:00
|
|
|
|
1.4.dev17026
|
|
|
|
|
1.4a1
|
|
|
|
|
1.4
|
2007-09-09 23:57:59 +02:00
|
|
|
|
|
2008-08-24 00:25:40 +02:00
|
|
|
|
Displaying debug output
|
|
|
|
|
-----------------------
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. program:: None
|
|
|
|
|
|
|
|
|
|
Use :option:`--verbosity` to specify the amount of notification and debug
|
|
|
|
|
information that ``django-admin`` prints to the console.
|
2008-08-24 00:25:40 +02:00
|
|
|
|
|
2010-10-23 18:37:51 +02:00
|
|
|
|
Available commands
|
|
|
|
|
==================
|
2007-09-09 23:57:59 +02:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``check``
|
|
|
|
|
---------
|
2013-06-15 01:02:29 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin:: check [app_label [app_label ...]]
|
2014-01-20 03:45:21 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Uses the :doc:`system check framework </ref/checks>` to inspect the entire
|
|
|
|
|
Django project for common problems.
|
2014-01-20 03:45:21 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
By default, all apps will be checked. You can check a subset of apps by
|
|
|
|
|
providing a list of app labels as arguments::
|
2013-06-15 19:14:30 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
django-admin check auth admin myapp
|
2013-06-15 01:02:29 +02:00
|
|
|
|
|
2014-01-20 03:45:21 +01:00
|
|
|
|
If you do not specify any app, all apps will be checked.
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --tag TAGS, -t TAGS
|
2014-01-20 03:45:21 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
The system check framework performs many different types of checks that are
|
|
|
|
|
:ref:`categorized with tags <system-check-builtin-tags>`. You can use these
|
|
|
|
|
tags to restrict the checks performed to just those in a particular category.
|
|
|
|
|
For example, to perform only models and compatibility checks, run::
|
2014-01-20 03:45:21 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
django-admin check --tag models --tag compatibility
|
2013-06-15 01:02:29 +02:00
|
|
|
|
|
2014-04-10 15:43:55 +02:00
|
|
|
|
.. django-admin-option:: --list-tags
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Lists all available tags.
|
2014-04-10 15:43:55 +02:00
|
|
|
|
|
2014-09-12 20:50:36 +02:00
|
|
|
|
.. django-admin-option:: --deploy
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Activates some additional checks that are only relevant in a deployment setting.
|
2014-09-12 20:50:36 +02:00
|
|
|
|
|
|
|
|
|
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::
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
django-admin check --deploy --settings=production_settings
|
2014-09-12 20:50:36 +02:00
|
|
|
|
|
|
|
|
|
Or you could run it directly on a production or staging deployment to verify
|
|
|
|
|
that the correct settings are in use (omitting ``--settings``). You could even
|
|
|
|
|
make it part of your integration test suite.
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --fail-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}
|
2015-10-04 20:16:12 +02:00
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.10
|
|
|
|
|
|
|
|
|
|
Specifies the message level that will cause the command to exit with a non-zero
|
|
|
|
|
status. Default is ``ERROR``.
|
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``compilemessages``
|
|
|
|
|
-------------------
|
2008-07-06 08:39:44 +02:00
|
|
|
|
|
2009-11-12 14:58:32 +01:00
|
|
|
|
.. django-admin:: compilemessages
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Compiles ``.po`` files created by :djadmin:`makemessages` to ``.mo`` files for
|
|
|
|
|
use with the built-in gettext support. See :doc:`/topics/i18n/index`.
|
2008-07-06 08:39:44 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --locale LOCALE, -l LOCALE
|
2008-07-06 08:39:44 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies the locale(s) to process. If not provided, all locales are processed.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --exclude EXCLUDE, -x EXCLUDE
|
|
|
|
|
|
|
|
|
|
Specifies the locale(s) to exclude from processing. If not provided, no locales
|
2014-03-24 14:03:06 +01:00
|
|
|
|
are excluded.
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --use-fuzzy, -f
|
|
|
|
|
|
|
|
|
|
Includes fuzzy translations into compiled files.
|
2014-11-15 23:56:37 +01:00
|
|
|
|
|
2015-04-16 13:55:37 +02:00
|
|
|
|
.. versionchanged:: 1.9
|
|
|
|
|
|
|
|
|
|
``compilemessages`` now matches the operation of :djadmin:`makemessages`,
|
|
|
|
|
scanning the project tree for ``.po`` files to compile.
|
|
|
|
|
|
2008-07-06 08:39:44 +02:00
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin compilemessages --locale=pt_BR
|
2014-11-15 23:56:37 +01:00
|
|
|
|
django-admin compilemessages --locale=pt_BR --locale=fr -f
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin compilemessages -l pt_BR
|
2014-11-15 23:56:37 +01:00
|
|
|
|
django-admin compilemessages -l pt_BR -l fr --use-fuzzy
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin compilemessages --exclude=pt_BR
|
|
|
|
|
django-admin compilemessages --exclude=pt_BR --exclude=fr
|
|
|
|
|
django-admin compilemessages -x pt_BR
|
|
|
|
|
django-admin compilemessages -x pt_BR -x fr
|
2012-06-07 11:23:25 +02:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``createcachetable``
|
|
|
|
|
--------------------
|
2005-09-26 00:03:30 +02:00
|
|
|
|
|
2009-11-12 14:58:32 +01:00
|
|
|
|
.. django-admin:: createcachetable
|
2005-09-26 00:03:30 +02:00
|
|
|
|
|
2015-01-26 21:39:52 +01:00
|
|
|
|
Creates the cache tables for use with the database cache backend using the
|
|
|
|
|
information from your settings file. See :doc:`/topics/cache` for more
|
|
|
|
|
information.
|
2005-09-26 00:03:30 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --database DATABASE
|
2013-01-05 23:43:01 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies the database in which the cache table(s) will be created. Defaults to
|
|
|
|
|
``default``.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --dry-run
|
|
|
|
|
|
|
|
|
|
Prints the SQL that would be run without actually running it, so you can
|
|
|
|
|
customize it or use the migrations framework.
|
2015-04-01 23:33:27 +02:00
|
|
|
|
|
|
|
|
|
.. versionchanged:: 1.9
|
|
|
|
|
|
|
|
|
|
The ``--dry-run`` option was added.
|
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``dbshell``
|
|
|
|
|
-----------
|
2008-06-11 06:34:03 +02:00
|
|
|
|
|
2008-08-24 00:25:40 +02:00
|
|
|
|
.. django-admin:: dbshell
|
|
|
|
|
|
2008-06-11 06:34:03 +02:00
|
|
|
|
Runs the command-line client for the database engine specified in your
|
2016-01-12 02:59:34 +01:00
|
|
|
|
:setting:`ENGINE <DATABASE-ENGINE>` setting, with the connection parameters
|
|
|
|
|
specified in your :setting:`USER`, :setting:`PASSWORD`, etc., settings.
|
2008-06-11 06:34:03 +02:00
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* For PostgreSQL, this runs the ``psql`` command-line client.
|
|
|
|
|
* For MySQL, this runs the ``mysql`` command-line client.
|
|
|
|
|
* For SQLite, this runs the ``sqlite3`` command-line client.
|
2015-09-15 22:01:31 +02:00
|
|
|
|
* For Oracle, this runs the ``sqlplus`` command-line client.
|
2008-06-11 06:34:03 +02:00
|
|
|
|
|
|
|
|
|
This command assumes the programs are on your ``PATH`` so that a simple call to
|
2015-09-15 22:01:31 +02:00
|
|
|
|
the program name (``psql``, ``mysql``, ``sqlite3``, ``sqlplus``) will find the
|
|
|
|
|
program in the right place. There's no way to specify the location of the
|
|
|
|
|
program manually.
|
2008-06-11 06:34:03 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --database DATABASE
|
|
|
|
|
|
|
|
|
|
Specifies the database onto which to open a shell. Defaults to ``default``.
|
2009-12-22 16:18:51 +01:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``diffsettings``
|
|
|
|
|
----------------
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2008-08-24 00:25:40 +02:00
|
|
|
|
.. django-admin:: diffsettings
|
|
|
|
|
|
2006-05-02 03:31:56 +02:00
|
|
|
|
Displays differences between the current settings file and Django's default
|
2008-10-02 14:57:13 +02:00
|
|
|
|
settings.
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2006-05-02 03:31:56 +02:00
|
|
|
|
Settings that don't appear in the defaults are followed by ``"###"``. For
|
2011-05-29 19:41:04 +02:00
|
|
|
|
example, the default settings don't define :setting:`ROOT_URLCONF`, so
|
|
|
|
|
:setting:`ROOT_URLCONF` is followed by ``"###"`` in the output of
|
|
|
|
|
``diffsettings``.
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --all
|
2013-03-17 20:48:30 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Displays all settings, even if they have Django's default value. Such settings
|
|
|
|
|
are prefixed by ``"###"``.
|
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``dumpdata``
|
|
|
|
|
------------
|
2008-08-24 00:25:40 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin:: dumpdata [app_label[.ModelName] [app_label[.ModelName] ...]]
|
2007-03-01 14:11:08 +01:00
|
|
|
|
|
2007-09-09 23:57:59 +02:00
|
|
|
|
Outputs to standard output all data in the database associated with the named
|
2007-03-01 14:11:08 +01:00
|
|
|
|
application(s).
|
|
|
|
|
|
|
|
|
|
If no application name is provided, all installed applications will be dumped.
|
|
|
|
|
|
2013-11-18 19:25:28 +01:00
|
|
|
|
The output of ``dumpdata`` can be used as input for :djadmin:`loaddata`.
|
2007-03-01 14:11:08 +01:00
|
|
|
|
|
2007-12-17 12:11:34 +01:00
|
|
|
|
Note that ``dumpdata`` uses the default manager on the model for selecting the
|
2008-08-24 00:25:40 +02:00
|
|
|
|
records to dump. If you're using a :ref:`custom manager <custom-managers>` as
|
|
|
|
|
the default manager and it filters some of the available records, not all of the
|
|
|
|
|
objects will be dumped.
|
2007-12-17 10:09:08 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --all, -a
|
2010-08-30 13:58:26 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Uses Django's base manager, dumping records which might otherwise be filtered
|
|
|
|
|
or modified by a custom manager.
|
2007-09-09 23:57:59 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --format FORMAT
|
2007-09-09 23:57:59 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies the serialization format of the output. Defaults to JSON. Supported
|
|
|
|
|
formats are listed in :ref:`serialization-formats`.
|
2007-09-09 23:57:59 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --indent INDENT
|
2007-09-09 23:57:59 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies the number of indentation spaces to use in the output. Defaults to
|
|
|
|
|
``None`` which displays all data on single line.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --exclude EXCLUDE, -e EXCLUDE
|
|
|
|
|
|
|
|
|
|
Prevents specific applications or models (specified in the form of
|
|
|
|
|
``app_label.ModelName``) from being dumped. If you specify a model name, the
|
2013-12-28 09:53:02 +01:00
|
|
|
|
output will be restricted to that model, rather than the entire application.
|
|
|
|
|
You can also mix application names and model names.
|
2009-02-28 06:35:22 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
If you want to exclude multiple applications, pass ``--exclude`` more than
|
|
|
|
|
once::
|
|
|
|
|
|
|
|
|
|
django-admin dumpdata --exclude=auth --exclude=contenttypes
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --database DATABASE
|
|
|
|
|
|
|
|
|
|
Specifies the database from which data will be dumped. Defaults to ``default``.
|
2009-12-22 16:18:51 +01:00
|
|
|
|
|
2012-08-01 03:49:01 +02:00
|
|
|
|
.. django-admin-option:: --natural-foreign
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Uses the ``natural_key()`` model method to serialize any foreign key and
|
|
|
|
|
many-to-many relationship to objects of the type that defines the method. If
|
|
|
|
|
you're dumping ``contrib.auth`` ``Permission`` objects or
|
|
|
|
|
``contrib.contenttypes`` ``ContentType`` objects, you should probably use this
|
|
|
|
|
flag. See the :ref:`natural keys <topics-serialization-natural-keys>`
|
|
|
|
|
documentation for more details on this and the next option.
|
2012-08-01 03:49:01 +02:00
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --natural-primary
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Omits the primary key in the serialized data of this object since it can be
|
|
|
|
|
calculated during deserialization.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --pks PRIMARY_KEYS
|
2012-08-01 03:49:01 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Outputs only the objects specified by a comma separated list of primary keys.
|
|
|
|
|
This is only available when dumping one model. By default, all the records of
|
|
|
|
|
the model are output.
|
2013-05-19 12:39:14 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --output OUTPUT, -o OUTPUT
|
2013-05-19 12:39:14 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies a file to write the serialized data to. By default, the data goes to
|
|
|
|
|
standard output.
|
2014-03-23 06:10:12 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
When this option is set and ``--verbosity`` is greater than 0 (the default), a
|
2015-07-21 23:24:32 +02:00
|
|
|
|
progress bar is shown in the terminal.
|
|
|
|
|
|
|
|
|
|
.. versionchanged:: 1.9
|
|
|
|
|
|
|
|
|
|
The progress bar in the terminal was added.
|
2014-03-23 06:10:12 +01:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``flush``
|
|
|
|
|
---------
|
2007-03-01 14:11:08 +01:00
|
|
|
|
|
2009-11-12 14:58:32 +01:00
|
|
|
|
.. django-admin:: flush
|
2008-08-24 00:25:40 +02:00
|
|
|
|
|
2015-04-27 19:17:52 +02:00
|
|
|
|
Removes all data from the database and re-executes any post-synchronization
|
|
|
|
|
handlers. The table of which migrations have been applied is not cleared.
|
|
|
|
|
|
|
|
|
|
If you would rather start from an empty database and re-run all migrations, you
|
|
|
|
|
should drop and recreate the database and then run :djadmin:`migrate` instead.
|
2007-03-01 14:11:08 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --noinput, --no-input
|
|
|
|
|
|
|
|
|
|
Suppresses all user prompts.
|
|
|
|
|
|
|
|
|
|
.. versionchanged:: 1.9
|
|
|
|
|
|
|
|
|
|
The ``--no-input`` alias was added.
|
2007-09-09 23:57:59 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --database DATABASE
|
|
|
|
|
|
|
|
|
|
Specifies the database to flush. Defaults to ``default``.
|
2009-12-22 16:18:51 +01:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``inspectdb``
|
|
|
|
|
-------------
|
2006-05-02 03:31:56 +02:00
|
|
|
|
|
2015-11-02 00:53:43 +01:00
|
|
|
|
.. django-admin:: inspectdb [table [table ...]]
|
2009-11-12 14:58:32 +01:00
|
|
|
|
|
2015-06-30 20:23:29 +02:00
|
|
|
|
Introspects the database tables in the database pointed-to by the
|
2011-05-29 19:41:04 +02:00
|
|
|
|
:setting:`NAME` setting and outputs a Django model module (a ``models.py``
|
2015-11-02 00:53:43 +01:00
|
|
|
|
file) to standard output. You may choose what tables to inspect by passing
|
|
|
|
|
their names as arguments.
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
|
|
|
|
Use this if you have a legacy database with which you'd like to use Django.
|
2015-06-30 20:23:29 +02:00
|
|
|
|
The script will inspect the database and create a model for each table within
|
|
|
|
|
it.
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2006-02-04 21:08:30 +01:00
|
|
|
|
As you might expect, the created models will have an attribute for every field
|
2015-06-30 20:23:29 +02:00
|
|
|
|
in the table. Note that ``inspectdb`` has a few special cases in its field-name
|
|
|
|
|
output:
|
2006-02-04 21:08:30 +01:00
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* If ``inspectdb`` cannot map a column's type to a model field type, it'll
|
|
|
|
|
use ``TextField`` and will insert the Python comment
|
|
|
|
|
``'This field type is a guess.'`` next to the field in the generated
|
|
|
|
|
model.
|
2006-02-04 21:08:30 +01:00
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* If the database column name is a Python reserved word (such as
|
|
|
|
|
``'pass'``, ``'class'`` or ``'for'``), ``inspectdb`` will append
|
|
|
|
|
``'_field'`` to the attribute name. For example, if a table has a column
|
|
|
|
|
``'for'``, the generated model will have a field ``'for_field'``, with
|
|
|
|
|
the ``db_column`` attribute set to ``'for'``. ``inspectdb`` will insert
|
|
|
|
|
the Python comment
|
|
|
|
|
``'Field renamed because it was a Python reserved word.'`` next to the
|
|
|
|
|
field.
|
2006-02-04 21:08:30 +01:00
|
|
|
|
|
2005-08-10 22:24:51 +02:00
|
|
|
|
This feature is meant as a shortcut, not as definitive model generation. After
|
|
|
|
|
you run it, you'll want to look over the generated models yourself to make
|
2006-02-18 22:26:28 +01:00
|
|
|
|
customizations. In particular, you'll need to rearrange models' order, so that
|
|
|
|
|
models that refer to other models are ordered properly.
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2006-07-07 06:06:00 +02:00
|
|
|
|
Primary keys are automatically introspected for PostgreSQL, MySQL and
|
|
|
|
|
SQLite, in which case Django puts in the ``primary_key=True`` where
|
|
|
|
|
needed.
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2005-11-29 03:05:32 +01:00
|
|
|
|
``inspectdb`` works with PostgreSQL, MySQL and SQLite. Foreign-key detection
|
2006-05-02 03:31:56 +02:00
|
|
|
|
only works in PostgreSQL and with certain types of MySQL tables.
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2014-08-19 12:14:14 +02:00
|
|
|
|
Django doesn't create database defaults when a
|
|
|
|
|
:attr:`~django.db.models.Field.default` is specified on a model field.
|
|
|
|
|
Similarly, database defaults aren't translated to model field defaults or
|
|
|
|
|
detected in any fashion by ``inspectdb``.
|
|
|
|
|
|
2014-03-25 15:17:23 +01:00
|
|
|
|
By default, ``inspectdb`` creates unmanaged models. That is, ``managed = False``
|
|
|
|
|
in the model's ``Meta`` class tells Django not to manage each table's creation,
|
|
|
|
|
modification, and deletion. If you do want to allow Django to manage the
|
|
|
|
|
table's lifecycle, you'll need to change the
|
|
|
|
|
:attr:`~django.db.models.Options.managed` option to ``True`` (or simply remove
|
|
|
|
|
it because ``True`` is its default value).
|
2013-02-03 01:08:45 +01:00
|
|
|
|
|
2015-11-02 00:53:43 +01:00
|
|
|
|
.. versionadded:: 1.10
|
|
|
|
|
|
|
|
|
|
Support for the ``table`` argument(s) to choose what tables should be
|
|
|
|
|
inspected was added.
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --database DATABASE
|
2009-12-22 16:18:51 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies the database to introspect. Defaults to ``default``.
|
2007-03-01 14:11:08 +01:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``loaddata``
|
|
|
|
|
------------
|
2016-01-12 02:59:34 +01:00
|
|
|
|
|
|
|
|
|
.. django-admin:: loaddata fixture [fixture ...]
|
2009-11-12 14:58:32 +01:00
|
|
|
|
|
2007-03-01 14:11:08 +01:00
|
|
|
|
Searches for and loads the contents of the named fixture into the database.
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --database DATABASE
|
|
|
|
|
|
|
|
|
|
Specifies the database into which the data will be loaded. Defaults to
|
|
|
|
|
``default``.
|
2009-12-22 16:18:51 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --ignorenonexistent, -i
|
2013-01-01 14:12:42 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Ignores fields and models that may have been removed since the fixture was
|
|
|
|
|
originally generated.
|
2014-02-09 13:22:29 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --app APP_LABEL
|
2014-12-19 05:52:01 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies a single app to look for fixtures in rather than looking in all apps.
|
2014-12-19 05:52:01 +01:00
|
|
|
|
|
2008-11-24 21:42:09 +01:00
|
|
|
|
What's a "fixture"?
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
2007-09-09 23:57:59 +02:00
|
|
|
|
A *fixture* is a collection of files that contain the serialized contents of
|
|
|
|
|
the database. Each fixture has a unique name, and the files that comprise the
|
|
|
|
|
fixture can be distributed over multiple directories, in multiple applications.
|
2007-03-01 14:11:08 +01:00
|
|
|
|
|
|
|
|
|
Django will search in three locations for fixtures:
|
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
|
1. In the ``fixtures`` directory of every installed application
|
|
|
|
|
2. In any directory named in the :setting:`FIXTURE_DIRS` setting
|
|
|
|
|
3. In the literal path named by the fixture
|
2007-03-01 14:11:08 +01:00
|
|
|
|
|
|
|
|
|
Django will load any and all fixtures it finds in these locations that match
|
2007-04-09 03:44:26 +02:00
|
|
|
|
the provided fixture names.
|
2007-03-01 14:11:08 +01:00
|
|
|
|
|
2007-04-09 03:44:26 +02:00
|
|
|
|
If the named fixture has a file extension, only fixtures of that type
|
2007-03-01 14:11:08 +01:00
|
|
|
|
will be loaded. For example::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin loaddata mydata.json
|
2007-04-09 03:44:26 +02:00
|
|
|
|
|
|
|
|
|
would only load JSON fixtures called ``mydata``. The fixture extension
|
2008-11-24 21:42:09 +01:00
|
|
|
|
must correspond to the registered name of a
|
|
|
|
|
:ref:`serializer <serialization-formats>` (e.g., ``json`` or ``xml``).
|
2007-03-01 14:11:08 +01:00
|
|
|
|
|
2008-11-24 21:42:09 +01:00
|
|
|
|
If you omit the extensions, Django will search all available fixture types
|
2007-03-01 14:11:08 +01:00
|
|
|
|
for a matching fixture. For example::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin loaddata mydata
|
2007-04-09 03:44:26 +02:00
|
|
|
|
|
2007-03-01 14:11:08 +01:00
|
|
|
|
would look for any fixture of any fixture type called ``mydata``. If a fixture
|
|
|
|
|
directory contained ``mydata.json``, that fixture would be loaded
|
2008-11-24 21:42:09 +01:00
|
|
|
|
as a JSON fixture.
|
2007-03-01 14:11:08 +01:00
|
|
|
|
|
2007-04-09 03:44:26 +02:00
|
|
|
|
The fixtures that are named can include directory components. These
|
2007-03-16 16:02:21 +01:00
|
|
|
|
directories will be included in the search path. For example::
|
2007-03-01 14:11:08 +01:00
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin loaddata foo/bar/mydata.json
|
2007-04-09 03:44:26 +02:00
|
|
|
|
|
2013-12-28 09:53:02 +01:00
|
|
|
|
would search ``<app_label>/fixtures/foo/bar/mydata.json`` for each installed
|
2007-04-09 03:44:26 +02:00
|
|
|
|
application, ``<dirname>/foo/bar/mydata.json`` for each directory in
|
2011-05-29 19:41:04 +02:00
|
|
|
|
:setting:`FIXTURE_DIRS`, and the literal path ``foo/bar/mydata.json``.
|
2007-03-01 14:11:08 +01:00
|
|
|
|
|
2009-04-01 01:34:03 +02:00
|
|
|
|
When fixture files are processed, the data is saved to the database as is.
|
2013-05-12 01:34:02 +02:00
|
|
|
|
Model defined :meth:`~django.db.models.Model.save` methods are not called, and
|
|
|
|
|
any :data:`~django.db.models.signals.pre_save` or
|
|
|
|
|
:data:`~django.db.models.signals.post_save` signals will be called with
|
|
|
|
|
``raw=True`` since the instance only contains attributes that are local to the
|
|
|
|
|
model. You may, for example, want to disable handlers that access
|
|
|
|
|
related fields that aren't present during fixture loading and would otherwise
|
|
|
|
|
raise an exception::
|
|
|
|
|
|
|
|
|
|
from django.db.models.signals import post_save
|
|
|
|
|
from .models import MyModel
|
|
|
|
|
|
|
|
|
|
def my_handler(**kwargs):
|
|
|
|
|
# disable the handler during fixture loading
|
|
|
|
|
if kwargs['raw']:
|
|
|
|
|
return
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
post_save.connect(my_handler, sender=MyModel)
|
|
|
|
|
|
|
|
|
|
You could also write a simple decorator to encapsulate this logic::
|
|
|
|
|
|
|
|
|
|
from functools import wraps
|
|
|
|
|
|
|
|
|
|
def disable_for_loaddata(signal_handler):
|
|
|
|
|
"""
|
|
|
|
|
Decorator that turns off signal handlers when loading fixture data.
|
|
|
|
|
"""
|
|
|
|
|
@wraps(signal_handler)
|
|
|
|
|
def wrapper(*args, **kwargs):
|
|
|
|
|
if kwargs['raw']:
|
|
|
|
|
return
|
|
|
|
|
signal_handler(*args, **kwargs)
|
|
|
|
|
return wrapper
|
|
|
|
|
|
|
|
|
|
@disable_for_loaddata
|
|
|
|
|
def my_handler(**kwargs):
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
Just be aware that this logic will disable the signals whenever fixtures are
|
|
|
|
|
deserialized, not just during ``loaddata``.
|
2009-04-01 01:34:03 +02:00
|
|
|
|
|
2007-03-01 14:11:08 +01:00
|
|
|
|
Note that the order in which fixture files are processed is undefined. However,
|
|
|
|
|
all fixture data is installed as a single transaction, so data in
|
|
|
|
|
one fixture can reference data in another fixture. If the database backend
|
|
|
|
|
supports row-level constraints, these constraints will be checked at the
|
|
|
|
|
end of the transaction.
|
|
|
|
|
|
2013-11-18 19:25:28 +01:00
|
|
|
|
The :djadmin:`dumpdata` command can be used to generate input for ``loaddata``.
|
2007-04-09 14:11:19 +02:00
|
|
|
|
|
2008-11-24 21:42:09 +01:00
|
|
|
|
Compressed fixtures
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Fixtures may be compressed in ``zip``, ``gz``, or ``bz2`` format. For example::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin loaddata mydata.json
|
2008-11-24 21:42:09 +01:00
|
|
|
|
|
|
|
|
|
would look for any of ``mydata.json``, ``mydata.json.zip``,
|
2012-02-03 18:52:39 +01:00
|
|
|
|
``mydata.json.gz``, or ``mydata.json.bz2``. The first file contained within a
|
2008-11-24 21:42:09 +01:00
|
|
|
|
zip-compressed archive is used.
|
|
|
|
|
|
|
|
|
|
Note that if two fixtures with the same name but different
|
|
|
|
|
fixture type are discovered (for example, if ``mydata.json`` and
|
|
|
|
|
``mydata.xml.gz`` were found in the same fixture directory), fixture
|
|
|
|
|
installation will be aborted, and any data installed in the call to
|
|
|
|
|
``loaddata`` will be removed from the database.
|
|
|
|
|
|
2012-02-19 08:39:05 +01:00
|
|
|
|
.. admonition:: MySQL with MyISAM and fixtures
|
|
|
|
|
|
|
|
|
|
The MyISAM storage engine of MySQL doesn't support transactions or
|
2012-03-02 18:16:52 +01:00
|
|
|
|
constraints, so if you use MyISAM, you won't get validation of fixture
|
|
|
|
|
data, or a rollback if multiple transaction files are found.
|
2007-04-09 03:44:26 +02:00
|
|
|
|
|
2009-12-22 16:18:51 +01:00
|
|
|
|
Database-specific fixtures
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
2011-04-20 18:28:02 +02:00
|
|
|
|
If you're in a multi-database setup, you might have fixture data that
|
2009-12-22 16:18:51 +01:00
|
|
|
|
you want to load onto one database, but not onto another. In this
|
2015-05-08 01:41:42 +02:00
|
|
|
|
situation, you can add a database identifier into the names of your fixtures.
|
2011-04-20 18:28:02 +02:00
|
|
|
|
|
|
|
|
|
For example, if your :setting:`DATABASES` setting has a 'master' database
|
|
|
|
|
defined, name the fixture ``mydata.master.json`` or
|
|
|
|
|
``mydata.master.json.gz`` and the fixture will only be loaded when you
|
|
|
|
|
specify you want to load data into the ``master`` database.
|
2009-12-22 16:18:51 +01:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``makemessages``
|
|
|
|
|
----------------
|
2008-07-06 08:39:44 +02:00
|
|
|
|
|
2009-11-12 14:58:32 +01:00
|
|
|
|
.. django-admin:: makemessages
|
|
|
|
|
|
2008-07-06 08:39:44 +02:00
|
|
|
|
Runs over the entire source tree of the current directory and pulls out all
|
|
|
|
|
strings marked for translation. It creates (or updates) a message file in the
|
2013-11-02 20:13:36 +01:00
|
|
|
|
conf/locale (in the Django tree) or locale (for project and application)
|
2008-07-06 08:39:44 +02:00
|
|
|
|
directory. After making changes to the messages files you need to compile them
|
2013-11-18 19:25:28 +01:00
|
|
|
|
with :djadmin:`compilemessages` for use with the builtin gettext support. See
|
|
|
|
|
the :ref:`i18n documentation <how-to-create-language-files>` for details.
|
2008-07-06 08:39:44 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --all, -a
|
2008-07-06 08:39:44 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Updates the message files for all available languages.
|
2008-07-06 08:39:44 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --extension EXTENSIONS, -e EXTENSIONS
|
2008-07-06 08:39:44 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies a list of file extensions to examine (default: ``html``, ``txt``,
|
|
|
|
|
``py`` or ``js`` if :option:`--domain` is ``js``).
|
2008-08-08 18:41:55 +02:00
|
|
|
|
|
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin makemessages --locale=de --extension xhtml
|
2008-08-08 18:41:55 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Separate multiple extensions with commas or use ``-e`` or ``--extension``
|
|
|
|
|
multiple times::
|
2008-08-08 18:41:55 +02:00
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin makemessages --locale=de --extension=html,txt --extension xml
|
2008-08-08 18:41:55 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --locale LOCALE, -l LOCALE
|
|
|
|
|
|
|
|
|
|
Specifies the locale(s) to process.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --exclude EXCLUDE, -x EXCLUDE
|
2008-07-06 08:39:44 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies the locale(s) to exclude from processing. If not provided, no locales
|
2014-03-24 14:03:06 +01:00
|
|
|
|
are excluded.
|
|
|
|
|
|
2008-07-06 08:39:44 +02:00
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin makemessages --locale=pt_BR
|
|
|
|
|
django-admin makemessages --locale=pt_BR --locale=fr
|
|
|
|
|
django-admin makemessages -l pt_BR
|
|
|
|
|
django-admin makemessages -l pt_BR -l fr
|
|
|
|
|
django-admin makemessages --exclude=pt_BR
|
|
|
|
|
django-admin makemessages --exclude=pt_BR --exclude=fr
|
|
|
|
|
django-admin makemessages -x pt_BR
|
|
|
|
|
django-admin makemessages -x pt_BR -x fr
|
2014-03-24 14:03:06 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --domain DOMAIN, -d DOMAIN
|
2008-07-06 08:39:44 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies the domain of the messages files. Supported options are:
|
2008-07-06 08:39:44 +02:00
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* ``django`` for all ``*.py``, ``*.html`` and ``*.txt`` files (default)
|
|
|
|
|
* ``djangojs`` for ``*.js`` files
|
2010-02-16 13:14:27 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --symlinks, -s
|
2010-02-16 13:14:27 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Follows symlinks to directories when looking for new translation strings.
|
2010-02-16 13:14:27 +01:00
|
|
|
|
|
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin makemessages --locale=de --symlinks
|
2008-07-06 08:39:44 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --ignore PATTERN, -i PATTERN
|
2010-02-16 13:15:04 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Ignores files or directories matching the given :mod:`glob`-style pattern. Use
|
|
|
|
|
multiple times to ignore more.
|
2010-02-16 13:15:04 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
These patterns are used by default: ``'CVS'``, ``'.*'``, ``'*~'``, ``'*.pyc'``.
|
2010-02-16 13:15:04 +01:00
|
|
|
|
|
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
|
2010-02-16 13:15:04 +01:00
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --no-default-ignore
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Disables the default values of ``--ignore``.
|
2010-02-16 13:15:04 +01:00
|
|
|
|
|
2010-11-04 13:08:37 +01:00
|
|
|
|
.. django-admin-option:: --no-wrap
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Disables breaking long message lines into several lines in language files.
|
2010-11-04 13:08:37 +01:00
|
|
|
|
|
2011-11-11 14:07:14 +01:00
|
|
|
|
.. django-admin-option:: --no-location
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Suppresses writing '``#: filename:line``’ comment lines in language files.
|
|
|
|
|
Using this option makes it harder for technically skilled translators to
|
|
|
|
|
understand each message's context.
|
2011-11-11 14:07:14 +01:00
|
|
|
|
|
2013-01-16 19:36:22 +01:00
|
|
|
|
.. django-admin-option:: --keep-pot
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Prevents deleting the temporary ``.pot`` files generated before creating the
|
|
|
|
|
``.po`` file. This is useful for debugging errors which may prevent the final
|
|
|
|
|
language files from being created.
|
2013-01-16 19:36:22 +01:00
|
|
|
|
|
2014-10-29 15:38:46 +01:00
|
|
|
|
.. seealso::
|
|
|
|
|
|
|
|
|
|
See :ref:`customizing-makemessages` for instructions on how to customize
|
|
|
|
|
the keywords that :djadmin:`makemessages` passes to ``xgettext``.
|
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``makemigrations``
|
|
|
|
|
------------------
|
2013-07-25 15:45:38 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin:: makemigrations [app_label [app_label ...]]
|
2013-07-25 15:45:38 +02:00
|
|
|
|
|
|
|
|
|
Creates new migrations based on the changes detected to your models.
|
|
|
|
|
Migrations, their relationship with apps and more are covered in depth in
|
|
|
|
|
:doc:`the migrations documentation</topics/migrations>`.
|
|
|
|
|
|
|
|
|
|
Providing one or more app names as arguments will limit the migrations created
|
2013-08-10 21:00:12 +02:00
|
|
|
|
to the app(s) specified and any dependencies needed (the table at the other end
|
|
|
|
|
of a ``ForeignKey``, for example).
|
2013-07-25 15:45:38 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --noinput, --no-input
|
|
|
|
|
|
|
|
|
|
Suppresses all user prompts. If a suppressed prompt cannot be resolved
|
|
|
|
|
automatically, the command will exit with error code 3.
|
|
|
|
|
|
2015-03-07 13:53:13 +01:00
|
|
|
|
.. versionchanged:: 1.9
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
The ``--no-input`` alias was added.
|
2015-03-07 13:53:13 +01:00
|
|
|
|
|
2013-07-25 15:45:38 +02:00
|
|
|
|
.. django-admin-option:: --empty
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Outputs an empty migration for the specified apps, for manual editing. This is
|
|
|
|
|
for advanced users and should not be used unless you are familiar with the
|
|
|
|
|
migration format, migration operations, and the dependencies between your
|
|
|
|
|
migrations.
|
2013-07-25 15:45:38 +02:00
|
|
|
|
|
2014-05-24 19:31:34 +02:00
|
|
|
|
.. django-admin-option:: --dry-run
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Shows what migrations would be made without actually writing any migrations
|
|
|
|
|
files to disk. Using this option along with ``--verbosity 3`` will also show
|
|
|
|
|
the complete migrations files that would be written.
|
2014-05-24 19:31:34 +02:00
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --merge
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Enables fixing of migration conflicts.
|
2014-05-24 19:31:34 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --name NAME, -n NAME
|
2014-08-19 15:24:31 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Allows naming the generated migration(s) instead of using a generated name.
|
2014-08-19 15:24:31 +02:00
|
|
|
|
|
2014-11-11 05:41:55 +01:00
|
|
|
|
.. django-admin-option:: --exit, -e
|
|
|
|
|
|
2015-10-21 02:39:48 +02:00
|
|
|
|
.. deprecated:: 1.10
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Use the ``--check`` option instead.
|
2015-10-21 02:39:48 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Makes ``makemigrations`` exit with error code 1 when no migrations are created
|
|
|
|
|
(or would have been created, if combined with ``--dry-run``).
|
2014-11-11 05:41:55 +01:00
|
|
|
|
|
2015-10-21 02:39:48 +02:00
|
|
|
|
.. django-admin-option:: --check
|
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.10
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Makes ``makemigrations`` exit with a non-zero status when model changes without
|
|
|
|
|
migrations are detected.
|
2015-10-21 02:39:48 +02:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``migrate``
|
|
|
|
|
-----------
|
2013-07-25 15:45:38 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin:: migrate [app_label] [migration_name]
|
2013-07-25 15:45:38 +02:00
|
|
|
|
|
2013-08-10 21:00:12 +02:00
|
|
|
|
Synchronizes the database state with the current set of models and migrations.
|
2013-07-25 15:45:38 +02:00
|
|
|
|
Migrations, their relationship with apps and more are covered in depth in
|
|
|
|
|
:doc:`the migrations documentation</topics/migrations>`.
|
|
|
|
|
|
2013-08-10 21:00:12 +02:00
|
|
|
|
The behavior of this command changes depending on the arguments provided:
|
2013-07-25 15:45:38 +02:00
|
|
|
|
|
2015-02-09 16:28:42 +01:00
|
|
|
|
* No arguments: All apps have all of their migrations run.
|
2013-12-28 09:53:02 +01:00
|
|
|
|
* ``<app_label>``: The specified app has its migrations run, up to the most
|
2013-07-25 15:45:38 +02:00
|
|
|
|
recent migration. This may involve running other apps' migrations too, due
|
|
|
|
|
to dependencies.
|
2014-11-17 18:13:47 +01:00
|
|
|
|
* ``<app_label> <migrationname>``: Brings the database schema to a state where
|
|
|
|
|
the named migration is applied, but no later migrations in the same app are
|
|
|
|
|
applied. This may involve unapplying migrations if you have previously
|
|
|
|
|
migrated past the named migration. Use the name ``zero`` to unapply all
|
|
|
|
|
migrations for an app.
|
2014-07-06 09:30:05 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --database DATABASE
|
|
|
|
|
|
|
|
|
|
Specifies the database to migrate. Defaults to ``default``.
|
2014-08-27 14:01:30 +02:00
|
|
|
|
|
2014-07-06 09:30:05 +02:00
|
|
|
|
.. django-admin-option:: --fake
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Tells Django to mark the migrations as having been applied or unapplied, but
|
|
|
|
|
without actually running the SQL to change your database schema.
|
2014-07-06 09:30:05 +02:00
|
|
|
|
|
|
|
|
|
This is intended for advanced users to manipulate the
|
|
|
|
|
current migration state directly if they're manually applying changes;
|
|
|
|
|
be warned that using ``--fake`` runs the risk of putting the migration state
|
|
|
|
|
table into a state where manual recovery will be needed to make migrations
|
|
|
|
|
run correctly.
|
|
|
|
|
|
2015-02-12 12:48:28 +01:00
|
|
|
|
.. django-admin-option:: --fake-initial
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Allows Django to skip an app's initial migration if all database tables with
|
|
|
|
|
the names of all models created by all
|
|
|
|
|
:class:`~django.db.migrations.operations.CreateModel` operations in that
|
2015-02-12 12:48:28 +01:00
|
|
|
|
migration already exist. This option is intended for use when first running
|
|
|
|
|
migrations against a database that preexisted the use of migrations. This
|
|
|
|
|
option does not, however, check for matching database schema beyond matching
|
|
|
|
|
table names and so is only safe to use if you are confident that your existing
|
|
|
|
|
schema matches what is recorded in your initial migration.
|
|
|
|
|
|
2015-08-31 16:33:52 +02:00
|
|
|
|
.. django-admin-option:: --run-syncdb
|
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.9
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Allows creating tables for apps without migrations. While this isn't
|
|
|
|
|
recommended, the migrations framework is sometimes too slow on large projects
|
|
|
|
|
with hundreds of models.
|
2015-08-31 16:33:52 +02:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``runserver``
|
|
|
|
|
-------------
|
Fixed a whole bunch of small docs typos, errors, and ommissions.
Fixes #8358, #8396, #8724, #9043, #9128, #9247, #9267, #9267, #9375, #9409, #9414, #9416, #9446, #9454, #9464, #9503, #9518, #9533, #9657, #9658, #9683, #9733, #9771, #9835, #9836, #9837, #9897, #9906, #9912, #9945, #9986, #9992, #10055, #10084, #10091, #10145, #10245, #10257, #10309, #10358, #10359, #10424, #10426, #10508, #10531, #10551, #10635, #10637, #10656, #10658, #10690, #10699, #19528.
Thanks to all the respective authors of those tickets.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10371 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-04-03 20:30:54 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin:: runserver [addrport]
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
|
|
|
|
Starts a lightweight development Web server on the local machine. By default,
|
2010-11-26 14:33:53 +01:00
|
|
|
|
the server runs on port 8000 on the IP address ``127.0.0.1``. You can pass in an
|
2005-08-19 23:23:56 +02:00
|
|
|
|
IP address and port number explicitly.
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
|
|
|
|
If you run this script as a user with normal privileges (recommended), you
|
|
|
|
|
might not have access to start a port on a low port number. Low port numbers
|
2006-05-02 03:31:56 +02:00
|
|
|
|
are reserved for the superuser (root).
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2012-12-26 21:47:29 +01:00
|
|
|
|
This server uses the WSGI application object specified by the
|
|
|
|
|
:setting:`WSGI_APPLICATION` setting.
|
2011-10-22 06:30:10 +02:00
|
|
|
|
|
2006-06-02 07:40:31 +02:00
|
|
|
|
DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through
|
|
|
|
|
security audits or performance tests. (And that's how it's gonna stay. We're in
|
|
|
|
|
the business of making Web frameworks, not Web servers, so improving this
|
|
|
|
|
server to be able to handle a production environment is outside the scope of
|
|
|
|
|
Django.)
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
|
|
|
|
The development server automatically reloads Python code for each request, as
|
|
|
|
|
needed. You don't need to restart the server for code changes to take effect.
|
2013-11-02 20:13:36 +01:00
|
|
|
|
However, some actions like adding files don't trigger a restart, so you'll
|
2013-11-02 10:28:22 +01:00
|
|
|
|
have to restart the server in these cases.
|
|
|
|
|
|
2013-10-14 07:33:45 +02:00
|
|
|
|
If you are using Linux and install `pyinotify`_, kernel signals will be used to
|
|
|
|
|
autoreload the server (rather than polling file modification timestamps each
|
|
|
|
|
second). This offers better scaling to large projects, reduction in response
|
|
|
|
|
time to code modification, more robust change detection, and battery usage
|
|
|
|
|
reduction.
|
|
|
|
|
|
|
|
|
|
.. _pyinotify: https://pypi.python.org/pypi/pyinotify/
|
|
|
|
|
|
2005-08-18 06:50:09 +02:00
|
|
|
|
When you start the server, and each time you change Python code while the
|
2015-04-25 21:05:48 +02:00
|
|
|
|
server is running, the system check framework will check your entire Django
|
|
|
|
|
project for some common errors (see the :djadmin:`check` command). If any
|
|
|
|
|
errors are found, they will be printed to standard output.
|
2005-08-18 06:50:09 +02:00
|
|
|
|
|
2015-05-08 01:41:42 +02:00
|
|
|
|
You can run as many concurrent servers as you want, as long as they're on
|
|
|
|
|
separate ports. Just execute ``django-admin runserver`` more than once.
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2010-11-26 14:33:53 +01:00
|
|
|
|
Note that the default IP address, ``127.0.0.1``, is not accessible from other
|
2005-10-17 15:05:55 +02:00
|
|
|
|
machines on your network. To make your development server viewable to other
|
|
|
|
|
machines on the network, use its own IP address (e.g. ``192.168.2.1``) or
|
2010-11-26 14:33:53 +01:00
|
|
|
|
``0.0.0.0`` or ``::`` (with IPv6 enabled).
|
|
|
|
|
|
2011-01-15 07:31:38 +01:00
|
|
|
|
You can provide an IPv6 address surrounded by brackets
|
|
|
|
|
(e.g. ``[200a::1]:8000``). This will automatically enable IPv6 support.
|
|
|
|
|
|
|
|
|
|
A hostname containing ASCII-only characters can also be used.
|
2005-10-17 15:05:55 +02:00
|
|
|
|
|
2011-01-30 18:23:30 +01:00
|
|
|
|
If the :doc:`staticfiles</ref/contrib/staticfiles>` contrib app is enabled
|
2013-07-28 03:45:25 +02:00
|
|
|
|
(default in new projects) the :djadmin:`runserver` command will be overridden
|
2012-09-28 02:25:31 +02:00
|
|
|
|
with its own :ref:`runserver<staticfiles-runserver>` command.
|
2011-01-30 18:23:30 +01:00
|
|
|
|
|
2014-11-24 14:32:07 +01:00
|
|
|
|
If :djadmin:`migrate` was not previously executed, the table that stores the
|
2014-11-15 11:53:36 +01:00
|
|
|
|
history of migrations is created at first run of ``runserver``.
|
|
|
|
|
|
2015-11-06 17:19:41 +01:00
|
|
|
|
Logging of each request and response of the server is sent to the
|
|
|
|
|
:ref:`django-server-logger` logger.
|
|
|
|
|
|
|
|
|
|
.. versionchanged:: 1.10
|
|
|
|
|
|
|
|
|
|
In older versions, log messages were written to ``sys.stderr`` instead of
|
|
|
|
|
being handled through Python logging.
|
|
|
|
|
|
Fixed a whole bunch of small docs typos, errors, and ommissions.
Fixes #8358, #8396, #8724, #9043, #9128, #9247, #9267, #9267, #9375, #9409, #9414, #9416, #9446, #9454, #9464, #9503, #9518, #9533, #9657, #9658, #9683, #9733, #9771, #9835, #9836, #9837, #9897, #9906, #9912, #9945, #9986, #9992, #10055, #10084, #10091, #10145, #10245, #10257, #10309, #10358, #10359, #10424, #10426, #10508, #10531, #10551, #10635, #10637, #10656, #10658, #10690, #10699, #19528.
Thanks to all the respective authors of those tickets.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10371 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-04-03 20:30:54 +02:00
|
|
|
|
.. django-admin-option:: --noreload
|
2007-09-09 23:57:59 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Disables the auto-reloader. This means any Python code changes you make while
|
|
|
|
|
the server is running will *not* take effect if the particular Python modules
|
|
|
|
|
have already been loaded into memory.
|
2008-06-16 05:37:57 +02:00
|
|
|
|
|
2011-06-17 15:08:36 +02:00
|
|
|
|
.. django-admin-option:: --nothreading
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Disables use of threading in the development server. The server is
|
|
|
|
|
multithreaded by default.
|
2011-06-17 15:08:36 +02:00
|
|
|
|
|
2010-11-26 14:33:53 +01:00
|
|
|
|
.. django-admin-option:: --ipv6, -6
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Uses IPv6 for the development server. This changes the default IP address from
|
2010-11-26 14:33:53 +01:00
|
|
|
|
``127.0.0.1`` to ``::1``.
|
|
|
|
|
|
2007-09-10 00:00:30 +02:00
|
|
|
|
Examples of using different ports and addresses
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
2010-11-26 14:33:53 +01:00
|
|
|
|
Port 8000 on IP address ``127.0.0.1``::
|
2007-09-10 00:00:30 +02:00
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin runserver
|
2007-09-10 00:00:30 +02:00
|
|
|
|
|
2010-11-26 14:33:53 +01:00
|
|
|
|
Port 8000 on IP address ``1.2.3.4``::
|
2007-09-10 00:00:30 +02:00
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin runserver 1.2.3.4:8000
|
2005-08-19 23:23:56 +02:00
|
|
|
|
|
2010-11-26 14:33:53 +01:00
|
|
|
|
Port 7000 on IP address ``127.0.0.1``::
|
2005-08-19 23:23:56 +02:00
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin runserver 7000
|
2005-08-19 23:23:56 +02:00
|
|
|
|
|
2010-11-26 14:33:53 +01:00
|
|
|
|
Port 7000 on IP address ``1.2.3.4``::
|
2005-08-19 23:23:56 +02:00
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin runserver 1.2.3.4:7000
|
2005-08-19 23:23:56 +02:00
|
|
|
|
|
2010-11-26 14:33:53 +01:00
|
|
|
|
Port 8000 on IPv6 address ``::1``::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin runserver -6
|
2010-11-26 14:33:53 +01:00
|
|
|
|
|
|
|
|
|
Port 7000 on IPv6 address ``::1``::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin runserver -6 7000
|
2010-11-26 14:33:53 +01:00
|
|
|
|
|
|
|
|
|
Port 7000 on IPv6 address ``2001:0db8:1234:5678::9``::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin runserver [2001:0db8:1234:5678::9]:7000
|
2010-11-26 14:33:53 +01:00
|
|
|
|
|
2011-01-15 07:31:38 +01:00
|
|
|
|
Port 8000 on IPv4 address of host ``localhost``::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin runserver localhost:8000
|
2011-01-15 07:31:38 +01:00
|
|
|
|
|
|
|
|
|
Port 8000 on IPv6 address of host ``localhost``::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin runserver -6 localhost:8000
|
2011-01-15 07:31:38 +01:00
|
|
|
|
|
2006-05-19 07:07:33 +02:00
|
|
|
|
Serving static files with the development server
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2006-05-19 05:47:59 +02:00
|
|
|
|
|
2006-05-19 07:07:33 +02:00
|
|
|
|
By default, the development server doesn't serve any static files for your site
|
2011-05-29 19:41:04 +02:00
|
|
|
|
(such as CSS files, images, things under :setting:`MEDIA_URL` and so forth). If
|
2013-03-07 20:15:39 +01:00
|
|
|
|
you want to configure Django to serve static media, read
|
|
|
|
|
:doc:`/howto/static-files/index`.
|
2008-08-24 00:25:40 +02:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``sendtestemail``
|
|
|
|
|
-----------------
|
2015-03-07 13:55:59 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin:: sendtestemail [email [email ...]]
|
2015-03-07 13:55:59 +01:00
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.9
|
|
|
|
|
|
|
|
|
|
Sends a test email (to confirm email sending through Django is working) to the
|
|
|
|
|
recipient(s) specified. For example::
|
|
|
|
|
|
|
|
|
|
django-admin sendtestemail foo@example.com bar@example.com
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
There are a couple of options, and you may use any combination of them
|
|
|
|
|
together:
|
|
|
|
|
|
2015-06-16 14:46:56 +02:00
|
|
|
|
.. django-admin-option:: --managers
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Mails the email addresses specified in :setting:`MANAGERS` using
|
|
|
|
|
:meth:`~django.core.mail.mail_managers()`.
|
2015-06-16 14:46:56 +02:00
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --admins
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Mails the email addresses specified in :setting:`ADMINS` using
|
|
|
|
|
:meth:`~django.core.mail.mail_admins()`.
|
2015-06-16 14:46:56 +02:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``shell``
|
|
|
|
|
---------
|
2006-01-12 21:56:10 +01:00
|
|
|
|
|
2009-11-12 14:58:32 +01:00
|
|
|
|
.. django-admin:: shell
|
|
|
|
|
|
2006-01-12 21:56:10 +01:00
|
|
|
|
Starts the Python interactive interpreter.
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --interface {ipython,bpython,python}, -i {ipython,bpython,python}
|
2006-01-12 21:56:10 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies the shell to use. By default, Django will use IPython_ or bpython_ if
|
|
|
|
|
either is installed. If both are installed, specify which one you want like so:
|
2012-07-17 02:37:52 +02:00
|
|
|
|
|
|
|
|
|
IPython::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin shell -i ipython
|
2012-07-17 02:37:52 +02:00
|
|
|
|
|
|
|
|
|
bpython::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin shell -i bpython
|
2012-07-17 02:37:52 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
If you have a "rich" shell installed but want to force use of the "plain"
|
|
|
|
|
Python interpreter, use ``python`` as the interface name, like so::
|
|
|
|
|
|
|
|
|
|
django-admin shell -i python
|
|
|
|
|
|
|
|
|
|
.. deprecated:: 1.10
|
|
|
|
|
|
|
|
|
|
In older versions, use the ``--plain`` option instead of ``-i python``. This
|
|
|
|
|
is deprecated and will be removed in Django 2.0.
|
2012-07-17 02:37:52 +02:00
|
|
|
|
|
2006-01-12 21:56:10 +01:00
|
|
|
|
.. _IPython: http://ipython.scipy.org/
|
2010-12-13 00:03:24 +01:00
|
|
|
|
.. _bpython: http://bpython-interpreter.org/
|
2006-01-12 21:56:10 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --nostartup
|
2013-01-25 01:21:26 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Disables reading the startup script for the "plain" Python interpreter. By
|
|
|
|
|
default, the script pointed to by the :envvar:`PYTHONSTARTUP` environment
|
|
|
|
|
variable or the ``~/.pythonrc.py`` script is read.
|
2013-01-25 01:21:26 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --command COMMAND, -c COMMAND
|
2015-11-07 12:07:28 +01:00
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.10
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Lets you pass a command as a string to execute it as Django, like so::
|
2015-11-07 12:07:28 +01:00
|
|
|
|
|
|
|
|
|
django-admin shell --command="import django; print(django.__version__)"
|
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``showmigrations``
|
|
|
|
|
------------------
|
2014-09-03 10:51:07 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin:: showmigrations [app_label [app_label ...]]
|
2014-09-03 10:51:07 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Shows all migrations in a project. You can choose from one of two formats:
|
2014-09-03 10:51:07 +02:00
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --list, -l
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Lists all of the apps Django knows about, the migrations available for each
|
|
|
|
|
app, and whether or not each migration is applied (marked by an ``[X]`` next to
|
|
|
|
|
the migration name).
|
2014-09-03 10:51:07 +02:00
|
|
|
|
|
|
|
|
|
Apps without migrations are also listed, but have ``(no migrations)`` printed
|
|
|
|
|
under them.
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
This is the default output format.
|
|
|
|
|
|
2014-09-03 10:51:07 +02:00
|
|
|
|
.. django-admin-option:: --plan, -p
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Shows the migration plan Django will follow to apply migrations. Any supplied
|
|
|
|
|
app labels are ignored because the plan might go beyond those apps. Like
|
|
|
|
|
``--list``, applied migrations are marked by an ``[X]``. For a ``--verbosity``
|
|
|
|
|
of 2 and above, all dependencies of a migration will also be shown.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --database DATABASE
|
|
|
|
|
|
|
|
|
|
Specifies the database to examine. Defaults to ``default``.
|
2014-09-03 10:51:07 +02:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``sqlflush``
|
|
|
|
|
------------
|
2007-08-25 21:32:30 +02:00
|
|
|
|
|
2009-11-12 14:58:32 +01:00
|
|
|
|
.. django-admin:: sqlflush
|
|
|
|
|
|
|
|
|
|
Prints the SQL statements that would be executed for the :djadmin:`flush`
|
|
|
|
|
command.
|
2007-08-25 21:32:30 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --database DATABASE
|
2009-12-22 16:18:51 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies the database for which to print the SQL. Defaults to ``default``.
|
2013-09-06 22:27:51 +02:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``sqlmigrate``
|
|
|
|
|
--------------
|
2016-01-12 02:59:34 +01:00
|
|
|
|
|
|
|
|
|
.. django-admin:: sqlmigrate app_label migration_name
|
2013-09-06 22:27:51 +02:00
|
|
|
|
|
|
|
|
|
Prints the SQL for the named migration. This requires an active database
|
|
|
|
|
connection, which it will use to resolve constraint names; this means you must
|
|
|
|
|
generate the SQL against a copy of the database you wish to later apply it on.
|
|
|
|
|
|
2014-08-16 17:21:14 +02:00
|
|
|
|
Note that ``sqlmigrate`` doesn't colorize its output.
|
|
|
|
|
|
2013-09-06 22:27:51 +02:00
|
|
|
|
.. django-admin-option:: --backwards
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Generates the SQL for unapplying the migration. By default, the SQL created is
|
|
|
|
|
for running the migration in the forwards direction.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --database DATABASE
|
|
|
|
|
|
|
|
|
|
Specifies the database for which to generate the SQL. Defaults to ``default``.
|
2013-09-06 22:27:51 +02:00
|
|
|
|
|
2015-03-29 16:59:35 +02:00
|
|
|
|
.. versionchanged:: 1.9
|
|
|
|
|
|
|
|
|
|
To increase the readability of the overall SQL output the SQL code
|
|
|
|
|
generated for each migration operation is preceded by the operation's
|
|
|
|
|
description.
|
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``sqlsequencereset``
|
|
|
|
|
--------------------
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin:: sqlsequencereset app_label [app_label ...]
|
2009-11-12 14:58:32 +01:00
|
|
|
|
|
2007-09-09 23:57:59 +02:00
|
|
|
|
Prints the SQL statements for resetting sequences for the given app name(s).
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2009-06-18 15:37:10 +02:00
|
|
|
|
Sequences are indexes used by some database engines to track the next available
|
|
|
|
|
number for automatically incremented fields.
|
|
|
|
|
|
|
|
|
|
Use this command to generate SQL which will fix cases where a sequence is out
|
|
|
|
|
of sync with its automatically incremented field data.
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --database DATABASE
|
2009-12-22 16:18:51 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies the database for which to print the SQL. Defaults to ``default``.
|
2014-04-14 19:07:02 +02:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``squashmigrations``
|
|
|
|
|
--------------------
|
2016-01-12 02:59:34 +01:00
|
|
|
|
|
|
|
|
|
.. django-admin:: squashmigrations app_label [start_migration_name] migration_name
|
2014-04-14 19:07:02 +02:00
|
|
|
|
|
|
|
|
|
Squashes the migrations for ``app_label`` up to and including ``migration_name``
|
|
|
|
|
down into fewer migrations, if possible. The resulting squashed migrations
|
|
|
|
|
can live alongside the unsquashed ones safely. For more information,
|
|
|
|
|
please read :ref:`migration-squashing`.
|
|
|
|
|
|
2015-09-12 09:18:24 +02:00
|
|
|
|
.. versionadded:: 1.9
|
|
|
|
|
|
|
|
|
|
When ``start_migration_name`` is given, Django will only include migrations
|
|
|
|
|
starting from and including this migration. This helps to mitigate the
|
|
|
|
|
squashing limitation of :class:`~django.db.migrations.operations.RunPython` and
|
|
|
|
|
:class:`django.db.migrations.operations.RunSQL` migration operations.
|
|
|
|
|
|
2014-04-14 19:07:02 +02:00
|
|
|
|
.. django-admin-option:: --no-optimize
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Disables the optimizer when generating a squashed migration. By default, Django
|
|
|
|
|
will try to optimize the operations in your migrations to reduce the size of
|
|
|
|
|
the resulting file. Use this option if this process is failing or creating
|
|
|
|
|
incorrect migrations, though please also file a Django bug report about the
|
|
|
|
|
behavior, as optimization is meant to be safe.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --noinput, --no-input
|
|
|
|
|
|
|
|
|
|
Suppresses all user prompts.
|
2014-04-14 19:07:02 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. versionchanged:: 1.9
|
2014-04-14 19:07:02 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
The ``--no-input`` alias was added.
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``startapp``
|
|
|
|
|
------------
|
2016-01-12 02:59:34 +01:00
|
|
|
|
|
|
|
|
|
.. django-admin:: startapp name [directory]
|
2009-11-12 14:58:32 +01:00
|
|
|
|
|
2005-08-10 22:24:51 +02:00
|
|
|
|
Creates a Django app directory structure for the given app name in the current
|
2011-12-22 23:38:02 +01:00
|
|
|
|
directory or the given destination.
|
|
|
|
|
|
|
|
|
|
By default the directory created contains a ``models.py`` file and other app
|
2011-12-30 19:14:31 +01:00
|
|
|
|
template files. (See the `source`_ for more details.) If only the app
|
2011-12-22 23:38:02 +01:00
|
|
|
|
name is given, the app directory will be created in the current working
|
2005-08-10 22:24:51 +02:00
|
|
|
|
directory.
|
|
|
|
|
|
2012-01-05 00:55:34 +01:00
|
|
|
|
If the optional destination is provided, Django will use that existing
|
|
|
|
|
directory rather than creating a new one. You can use '.' to denote the current
|
|
|
|
|
working directory.
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
2011-12-30 19:14:31 +01:00
|
|
|
|
For example::
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin startapp myapp /Users/jezdez/Code/myapp
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
Simplified default project template.
Squashed commit of:
commit 508ec9144b35c50794708225b496bde1eb5e60aa
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 22:50:55 2013 +0100
Tweaked default settings file.
* Explained why BASE_DIR exists.
* Added a link to the database configuration options, and put it in its
own section.
* Moved sensitive settings that must be changed for production at the
top.
commit 6515fd2f1aa73a86dc8dbd2ccf512ddb6b140d57
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 14:35:21 2013 +0100
Documented the simplified app & project templates in the changelog.
commit 2c5b576c2ea91d84273a019b3d0b3b8b4da72f23
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 13:59:27 2013 +0100
Minor fixes in tutorials 5 and 6.
commit 55a51531be8104f21b3cca3f6bf70b0a7139a041
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 13:51:11 2013 +0100
Updated tutorial 2 for the new project template.
commit 29ddae87bdaecff12dd31b16b000c01efbde9e20
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 11:58:54 2013 +0100
Updated tutorial 1 for the new project template.
commit 0ecb9f6e2514cfd26a678a280d471433375101a3
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 11:29:13 2013 +0100
Adjusted the default URLconf detection to account for the admin.
It's now enabled by default.
commit 5fb4da0d3d09dac28dd94e3fde92b9d4335c0565
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 10:36:55 2013 +0100
Added security warnings for the most sensitive settings.
commit 718d84bd8ac4a42fb4b28ec93965de32680f091e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:24:06 2013 +0100
Used an absolute path for the SQLite database.
This ensures the settings file works regardless of which directory
django-admin.py / manage.py is invoked from.
BASE_DIR got a +1 from a BDFL and another core dev. It doesn't involve
the concept of a "Django project"; it's just a convenient way to express
relative paths within the source code repository for non-Python files.
Thanks Jacob Kaplan-Moss for the suggestion.
commit 1b559b4bcda622e10909b68fe5cab90db6727dd9
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:22:40 2013 +0100
Removed STATIC_ROOT from the default settings template.
It isn't necessary in development, and it confuses beginners to no end.
Thanks Carl Meyer for the suggestion.
commit a55f141a500bb7c9a1bc259bbe1954c13b199671
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:21:43 2013 +0100
Removed MEDIA_ROOT/URL from default settings template.
Many sites will never deal with user-uploaded files, and MEDIA_ROOT is
complicated to explain.
Thanks Carl Meyer for the suggestion.
commit 44bf2f2441420fd9429ee9fe1f7207f92dd87e70
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:22:09 2013 +0100
Removed logging config.
This configuration is applied regardless of the value of LOGGING;
duplicating it in LOGGING is confusing.
commit eac747e848eaed65fd5f6f254f0a7559d856f88f
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:05:31 2013 +0100
Enabled the locale middleware by default.
USE_I18N is True by default, and doesn't work well without
LocaleMiddleware.
commit d806c62b2d00826dc2688c84b092627b8d571cab
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:03:16 2013 +0100
Enabled clickjacking protection by default.
commit 99152c30e6a15003f0b6737dc78e87adf462aacb
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:01:48 2013 +0100
Reorganized settings in logical sections, and trimmed comments.
commit d37ffdfcb24b7e0ec7cc113d07190f65fb12fb8a
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:54:11 2013 +0100
Avoided misleading TEMPLATE_DEBUG = DEBUG.
According to the docs TEMPLATE_DEBUG works only when DEBUG = True.
commit 15d9478d3a9850e85841e7cf09cf83050371c6bf
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:46:25 2013 +0100
Removed STATICFILES_FINDERS/TEMPLATE_LOADERS from default settings file.
Only developers with special needs ever need to change these settings.
commit 574da0eb5bfb4570883756914b4dbd7e20e1f61e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:45:01 2013 +0100
Removed STATICFILES/TEMPLATES_DIRS from default settings file.
The current best practice is to put static files and templates in
applications, for easier testing and deployment.
commit 8cb18dbe56629aa1be74718a07e7cc66b4f9c9f0
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:24:16 2013 +0100
Removed settings related to email reporting from default settings file.
While handy for small scale projects, it isn't exactly a best practice.
commit 8ecbfcb3638058f0c49922540f874a7d802d864f
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 18:54:43 2013 +0100
Documented how to enable the sites framework.
commit 23fc91a6fa67d91ddd9d71b1c3e0dc26bdad9841
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:28:59 2013 +0100
Disabled the sites framework by default.
RequestSite does the job for single-domain websites.
commit c4d82eb8afc0eb8568bf9c4d12644272415e3960
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 00:08:33 2013 +0100
Added a default admin.py to the application template.
Thanks Ryan D Hiebert for the suggestion.
commit 4071dc771e5c44b1c5ebb9beecefb164ae465e22
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 10:59:49 2013 +0100
Enabled the admin by default.
Everyone uses the admin.
commit c807a31f8d89e7e7fd97380e3023f7983a8b6fcb
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 10:57:05 2013 +0100
Removed admindocs from default project template.
commit 09e4ce0e652a97da1a9e285046a91c8ad7a9189c
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:32:52 2013 +0100
Added links to the settings documentation.
commit 5b8f5eaef364eb790fcde6f9e86f7d266074cca8
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 11:06:54 2013 +0100
Used a significant example for URLconf includes.
commit 908e91d6fcee2a3cb51ca26ecdf12a6a24e69ef8
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:22:31 2013 +0100
Moved code comments about WSGI to docs, and rewrote said docs.
commit 50417e51996146f891d08ca8b74dcc736a581932
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 15:51:50 2013 +0100
Normalized the default application template.
Removed the default test that 1 + 1 = 2, because it's been committed
way too many times, in too many projects.
Added an import of `render` for views, because the first view will
often be:
def home(request):
return render(request, "mysite/home.html")
2013-01-28 15:51:50 +01:00
|
|
|
|
.. _custom-app-and-project-templates:
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --template TEMPLATE
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Provides the path to a directory with a custom app template file or a path to a
|
2011-12-22 23:38:02 +01:00
|
|
|
|
compressed file (``.tar.gz``, ``.tar.bz2``, ``.tgz``, ``.tbz``, ``.zip``)
|
|
|
|
|
containing the app template files.
|
|
|
|
|
|
2012-11-16 06:17:58 +01:00
|
|
|
|
For example, this would look for an app template in the given directory when
|
|
|
|
|
creating the ``myapp`` app::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp
|
2012-11-16 06:17:58 +01:00
|
|
|
|
|
2011-12-30 19:14:31 +01:00
|
|
|
|
Django will also accept URLs (``http``, ``https``, ``ftp``) to compressed
|
|
|
|
|
archives with the app template files, downloading and extracting them on the
|
|
|
|
|
fly.
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
2015-10-21 06:50:20 +02:00
|
|
|
|
For example, taking advantage of GitHub's feature to expose repositories as
|
2012-11-16 06:17:58 +01:00
|
|
|
|
zip files, you can use a URL like::
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/master.zip myapp
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --extension EXTENSIONS, -e EXTENSIONS
|
|
|
|
|
|
|
|
|
|
Specifies which file extensions in the app template should be rendered with the
|
|
|
|
|
template engine. Defaults to ``py``.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --name FILES, -n FILES
|
|
|
|
|
|
|
|
|
|
Specifies which files in the app template (in addition to those matching
|
|
|
|
|
``--extension``) should be rendered with the template engine. Defaults to an
|
|
|
|
|
empty list.
|
|
|
|
|
|
|
|
|
|
The :class:`template context <django.template.Context>` used for all matching
|
|
|
|
|
files is:
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
2014-03-11 13:09:44 +01:00
|
|
|
|
- Any option passed to the ``startapp`` command (among the command's supported
|
2012-07-07 23:08:43 +02:00
|
|
|
|
options)
|
2011-12-30 19:14:31 +01:00
|
|
|
|
- ``app_name`` -- the app name as passed to the command
|
2011-12-22 23:38:02 +01:00
|
|
|
|
- ``app_directory`` -- the full path of the newly created app
|
2015-06-13 15:41:56 +02:00
|
|
|
|
- ``camel_case_app_name`` -- the app name in camel case format
|
Simplified default project template.
Squashed commit of:
commit 508ec9144b35c50794708225b496bde1eb5e60aa
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 22:50:55 2013 +0100
Tweaked default settings file.
* Explained why BASE_DIR exists.
* Added a link to the database configuration options, and put it in its
own section.
* Moved sensitive settings that must be changed for production at the
top.
commit 6515fd2f1aa73a86dc8dbd2ccf512ddb6b140d57
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 14:35:21 2013 +0100
Documented the simplified app & project templates in the changelog.
commit 2c5b576c2ea91d84273a019b3d0b3b8b4da72f23
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 13:59:27 2013 +0100
Minor fixes in tutorials 5 and 6.
commit 55a51531be8104f21b3cca3f6bf70b0a7139a041
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 13:51:11 2013 +0100
Updated tutorial 2 for the new project template.
commit 29ddae87bdaecff12dd31b16b000c01efbde9e20
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 11:58:54 2013 +0100
Updated tutorial 1 for the new project template.
commit 0ecb9f6e2514cfd26a678a280d471433375101a3
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 11:29:13 2013 +0100
Adjusted the default URLconf detection to account for the admin.
It's now enabled by default.
commit 5fb4da0d3d09dac28dd94e3fde92b9d4335c0565
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 10:36:55 2013 +0100
Added security warnings for the most sensitive settings.
commit 718d84bd8ac4a42fb4b28ec93965de32680f091e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:24:06 2013 +0100
Used an absolute path for the SQLite database.
This ensures the settings file works regardless of which directory
django-admin.py / manage.py is invoked from.
BASE_DIR got a +1 from a BDFL and another core dev. It doesn't involve
the concept of a "Django project"; it's just a convenient way to express
relative paths within the source code repository for non-Python files.
Thanks Jacob Kaplan-Moss for the suggestion.
commit 1b559b4bcda622e10909b68fe5cab90db6727dd9
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:22:40 2013 +0100
Removed STATIC_ROOT from the default settings template.
It isn't necessary in development, and it confuses beginners to no end.
Thanks Carl Meyer for the suggestion.
commit a55f141a500bb7c9a1bc259bbe1954c13b199671
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:21:43 2013 +0100
Removed MEDIA_ROOT/URL from default settings template.
Many sites will never deal with user-uploaded files, and MEDIA_ROOT is
complicated to explain.
Thanks Carl Meyer for the suggestion.
commit 44bf2f2441420fd9429ee9fe1f7207f92dd87e70
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:22:09 2013 +0100
Removed logging config.
This configuration is applied regardless of the value of LOGGING;
duplicating it in LOGGING is confusing.
commit eac747e848eaed65fd5f6f254f0a7559d856f88f
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:05:31 2013 +0100
Enabled the locale middleware by default.
USE_I18N is True by default, and doesn't work well without
LocaleMiddleware.
commit d806c62b2d00826dc2688c84b092627b8d571cab
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:03:16 2013 +0100
Enabled clickjacking protection by default.
commit 99152c30e6a15003f0b6737dc78e87adf462aacb
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:01:48 2013 +0100
Reorganized settings in logical sections, and trimmed comments.
commit d37ffdfcb24b7e0ec7cc113d07190f65fb12fb8a
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:54:11 2013 +0100
Avoided misleading TEMPLATE_DEBUG = DEBUG.
According to the docs TEMPLATE_DEBUG works only when DEBUG = True.
commit 15d9478d3a9850e85841e7cf09cf83050371c6bf
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:46:25 2013 +0100
Removed STATICFILES_FINDERS/TEMPLATE_LOADERS from default settings file.
Only developers with special needs ever need to change these settings.
commit 574da0eb5bfb4570883756914b4dbd7e20e1f61e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:45:01 2013 +0100
Removed STATICFILES/TEMPLATES_DIRS from default settings file.
The current best practice is to put static files and templates in
applications, for easier testing and deployment.
commit 8cb18dbe56629aa1be74718a07e7cc66b4f9c9f0
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:24:16 2013 +0100
Removed settings related to email reporting from default settings file.
While handy for small scale projects, it isn't exactly a best practice.
commit 8ecbfcb3638058f0c49922540f874a7d802d864f
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 18:54:43 2013 +0100
Documented how to enable the sites framework.
commit 23fc91a6fa67d91ddd9d71b1c3e0dc26bdad9841
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:28:59 2013 +0100
Disabled the sites framework by default.
RequestSite does the job for single-domain websites.
commit c4d82eb8afc0eb8568bf9c4d12644272415e3960
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 00:08:33 2013 +0100
Added a default admin.py to the application template.
Thanks Ryan D Hiebert for the suggestion.
commit 4071dc771e5c44b1c5ebb9beecefb164ae465e22
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 10:59:49 2013 +0100
Enabled the admin by default.
Everyone uses the admin.
commit c807a31f8d89e7e7fd97380e3023f7983a8b6fcb
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 10:57:05 2013 +0100
Removed admindocs from default project template.
commit 09e4ce0e652a97da1a9e285046a91c8ad7a9189c
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:32:52 2013 +0100
Added links to the settings documentation.
commit 5b8f5eaef364eb790fcde6f9e86f7d266074cca8
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 11:06:54 2013 +0100
Used a significant example for URLconf includes.
commit 908e91d6fcee2a3cb51ca26ecdf12a6a24e69ef8
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:22:31 2013 +0100
Moved code comments about WSGI to docs, and rewrote said docs.
commit 50417e51996146f891d08ca8b74dcc736a581932
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 15:51:50 2013 +0100
Normalized the default application template.
Removed the default test that 1 + 1 = 2, because it's been committed
way too many times, in too many projects.
Added an import of `render` for views, because the first view will
often be:
def home(request):
return render(request, "mysite/home.html")
2013-01-28 15:51:50 +01:00
|
|
|
|
- ``docs_version`` -- the version of the documentation: ``'dev'`` or ``'1.x'``
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
2015-06-13 15:41:56 +02:00
|
|
|
|
.. versionadded:: 1.9
|
|
|
|
|
|
|
|
|
|
``camel_case_app_name`` was added.
|
|
|
|
|
|
2011-12-22 23:38:02 +01:00
|
|
|
|
.. _render_warning:
|
|
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
|
|
|
|
When the app template files are rendered with the Django template
|
2011-12-30 19:14:31 +01:00
|
|
|
|
engine (by default all ``*.py`` files), Django will also replace all
|
|
|
|
|
stray template variables contained. For example, if one of the Python files
|
|
|
|
|
contains a docstring explaining a particular feature related
|
2011-12-22 23:38:02 +01:00
|
|
|
|
to template rendering, it might result in an incorrect example.
|
|
|
|
|
|
2011-12-30 19:14:31 +01:00
|
|
|
|
To work around this problem, you can use the :ttag:`templatetag`
|
2011-12-22 23:38:02 +01:00
|
|
|
|
templatetag to "escape" the various parts of the template syntax.
|
|
|
|
|
|
2016-01-24 10:06:01 +01:00
|
|
|
|
In addition, to allow Python template files that contain Django template
|
|
|
|
|
language syntax while also preventing packaging systems from trying to
|
|
|
|
|
byte-compile invalid ``*.py`` files, template files ending with ``.py-tpl``
|
|
|
|
|
will be renamed to ``.py``.
|
|
|
|
|
|
|
|
|
|
.. versionchanged:: 1.9.2
|
|
|
|
|
|
|
|
|
|
Renaming of ``.py-tpl`` to ``.py`` was added.
|
|
|
|
|
|
2012-05-03 17:42:56 +02:00
|
|
|
|
.. _source: https://github.com/django/django/tree/master/django/conf/app_template/
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``startproject``
|
|
|
|
|
----------------
|
2005-08-10 22:24:51 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin:: startproject name [directory]
|
2009-11-12 14:58:32 +01:00
|
|
|
|
|
2011-12-22 23:38:02 +01:00
|
|
|
|
Creates a Django project directory structure for the given project name in
|
|
|
|
|
the current directory or the given destination.
|
|
|
|
|
|
2011-12-30 19:14:31 +01:00
|
|
|
|
By default, the new directory contains ``manage.py`` and a project package
|
2012-02-03 18:52:39 +01:00
|
|
|
|
(containing a ``settings.py`` and other files). See the `template source`_ for
|
2012-01-05 00:55:34 +01:00
|
|
|
|
details.
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
|
|
|
|
If only the project name is given, both the project directory and project
|
|
|
|
|
package will be named ``<projectname>`` and the project directory
|
|
|
|
|
will be created in the current working directory.
|
|
|
|
|
|
2012-01-05 00:55:34 +01:00
|
|
|
|
If the optional destination is provided, Django will use that existing
|
|
|
|
|
directory as the project directory, and create ``manage.py`` and the project
|
2012-02-03 18:52:39 +01:00
|
|
|
|
package within it. Use '.' to denote the current working directory.
|
2011-12-30 19:14:31 +01:00
|
|
|
|
|
|
|
|
|
For example::
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin startproject myproject /Users/jezdez/Code/myproject_repo
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --template TEMPLATE
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies a directory, file path, or URL of a custom project template. See the
|
|
|
|
|
:option:`startapp --template` documentation for examples and usage.
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --extension EXTENSIONS, -e EXTENSIONS
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies which file extensions in the project template should be rendered with
|
|
|
|
|
the template engine. Defaults to ``py``.
|
2012-11-16 06:17:58 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --name FILES, -n FILES
|
2012-11-16 06:17:58 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies which files in the project template (in addition to those matching
|
|
|
|
|
``--extension``) should be rendered with the template engine. Defaults to an
|
|
|
|
|
empty list.
|
2012-11-16 06:17:58 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
The :class:`template context <django.template.Context>` used is:
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
2014-03-11 13:09:44 +01:00
|
|
|
|
- Any option passed to the ``startproject`` command (among the command's
|
|
|
|
|
supported options)
|
2011-12-22 23:38:02 +01:00
|
|
|
|
- ``project_name`` -- the project name as passed to the command
|
|
|
|
|
- ``project_directory`` -- the full path of the newly created project
|
|
|
|
|
- ``secret_key`` -- a random key for the :setting:`SECRET_KEY` setting
|
Simplified default project template.
Squashed commit of:
commit 508ec9144b35c50794708225b496bde1eb5e60aa
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 22:50:55 2013 +0100
Tweaked default settings file.
* Explained why BASE_DIR exists.
* Added a link to the database configuration options, and put it in its
own section.
* Moved sensitive settings that must be changed for production at the
top.
commit 6515fd2f1aa73a86dc8dbd2ccf512ddb6b140d57
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 14:35:21 2013 +0100
Documented the simplified app & project templates in the changelog.
commit 2c5b576c2ea91d84273a019b3d0b3b8b4da72f23
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 13:59:27 2013 +0100
Minor fixes in tutorials 5 and 6.
commit 55a51531be8104f21b3cca3f6bf70b0a7139a041
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 13:51:11 2013 +0100
Updated tutorial 2 for the new project template.
commit 29ddae87bdaecff12dd31b16b000c01efbde9e20
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 11:58:54 2013 +0100
Updated tutorial 1 for the new project template.
commit 0ecb9f6e2514cfd26a678a280d471433375101a3
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 11:29:13 2013 +0100
Adjusted the default URLconf detection to account for the admin.
It's now enabled by default.
commit 5fb4da0d3d09dac28dd94e3fde92b9d4335c0565
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 10:36:55 2013 +0100
Added security warnings for the most sensitive settings.
commit 718d84bd8ac4a42fb4b28ec93965de32680f091e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:24:06 2013 +0100
Used an absolute path for the SQLite database.
This ensures the settings file works regardless of which directory
django-admin.py / manage.py is invoked from.
BASE_DIR got a +1 from a BDFL and another core dev. It doesn't involve
the concept of a "Django project"; it's just a convenient way to express
relative paths within the source code repository for non-Python files.
Thanks Jacob Kaplan-Moss for the suggestion.
commit 1b559b4bcda622e10909b68fe5cab90db6727dd9
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:22:40 2013 +0100
Removed STATIC_ROOT from the default settings template.
It isn't necessary in development, and it confuses beginners to no end.
Thanks Carl Meyer for the suggestion.
commit a55f141a500bb7c9a1bc259bbe1954c13b199671
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:21:43 2013 +0100
Removed MEDIA_ROOT/URL from default settings template.
Many sites will never deal with user-uploaded files, and MEDIA_ROOT is
complicated to explain.
Thanks Carl Meyer for the suggestion.
commit 44bf2f2441420fd9429ee9fe1f7207f92dd87e70
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:22:09 2013 +0100
Removed logging config.
This configuration is applied regardless of the value of LOGGING;
duplicating it in LOGGING is confusing.
commit eac747e848eaed65fd5f6f254f0a7559d856f88f
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:05:31 2013 +0100
Enabled the locale middleware by default.
USE_I18N is True by default, and doesn't work well without
LocaleMiddleware.
commit d806c62b2d00826dc2688c84b092627b8d571cab
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:03:16 2013 +0100
Enabled clickjacking protection by default.
commit 99152c30e6a15003f0b6737dc78e87adf462aacb
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:01:48 2013 +0100
Reorganized settings in logical sections, and trimmed comments.
commit d37ffdfcb24b7e0ec7cc113d07190f65fb12fb8a
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:54:11 2013 +0100
Avoided misleading TEMPLATE_DEBUG = DEBUG.
According to the docs TEMPLATE_DEBUG works only when DEBUG = True.
commit 15d9478d3a9850e85841e7cf09cf83050371c6bf
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:46:25 2013 +0100
Removed STATICFILES_FINDERS/TEMPLATE_LOADERS from default settings file.
Only developers with special needs ever need to change these settings.
commit 574da0eb5bfb4570883756914b4dbd7e20e1f61e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:45:01 2013 +0100
Removed STATICFILES/TEMPLATES_DIRS from default settings file.
The current best practice is to put static files and templates in
applications, for easier testing and deployment.
commit 8cb18dbe56629aa1be74718a07e7cc66b4f9c9f0
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:24:16 2013 +0100
Removed settings related to email reporting from default settings file.
While handy for small scale projects, it isn't exactly a best practice.
commit 8ecbfcb3638058f0c49922540f874a7d802d864f
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 18:54:43 2013 +0100
Documented how to enable the sites framework.
commit 23fc91a6fa67d91ddd9d71b1c3e0dc26bdad9841
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:28:59 2013 +0100
Disabled the sites framework by default.
RequestSite does the job for single-domain websites.
commit c4d82eb8afc0eb8568bf9c4d12644272415e3960
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 00:08:33 2013 +0100
Added a default admin.py to the application template.
Thanks Ryan D Hiebert for the suggestion.
commit 4071dc771e5c44b1c5ebb9beecefb164ae465e22
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 10:59:49 2013 +0100
Enabled the admin by default.
Everyone uses the admin.
commit c807a31f8d89e7e7fd97380e3023f7983a8b6fcb
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 10:57:05 2013 +0100
Removed admindocs from default project template.
commit 09e4ce0e652a97da1a9e285046a91c8ad7a9189c
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:32:52 2013 +0100
Added links to the settings documentation.
commit 5b8f5eaef364eb790fcde6f9e86f7d266074cca8
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 11:06:54 2013 +0100
Used a significant example for URLconf includes.
commit 908e91d6fcee2a3cb51ca26ecdf12a6a24e69ef8
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:22:31 2013 +0100
Moved code comments about WSGI to docs, and rewrote said docs.
commit 50417e51996146f891d08ca8b74dcc736a581932
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 15:51:50 2013 +0100
Normalized the default application template.
Removed the default test that 1 + 1 = 2, because it's been committed
way too many times, in too many projects.
Added an import of `render` for views, because the first view will
often be:
def home(request):
return render(request, "mysite/home.html")
2013-01-28 15:51:50 +01:00
|
|
|
|
- ``docs_version`` -- the version of the documentation: ``'dev'`` or ``'1.x'``
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
|
|
|
|
Please also see the :ref:`rendering warning <render_warning>` as mentioned
|
|
|
|
|
for :djadmin:`startapp`.
|
|
|
|
|
|
2012-05-03 17:42:56 +02:00
|
|
|
|
.. _`template source`: https://github.com/django/django/tree/master/django/conf/project_template/
|
2011-12-22 23:38:02 +01:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``test``
|
|
|
|
|
--------
|
2007-09-09 23:57:59 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin:: test [test_label [test_label ...]]
|
2006-08-29 20:04:09 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Runs tests for all installed apps. See :doc:`/topics/testing/index` for more
|
2008-08-24 00:25:40 +02:00
|
|
|
|
information.
|
2007-08-17 01:05:00 +02:00
|
|
|
|
|
2009-12-31 19:48:28 +01:00
|
|
|
|
.. django-admin-option:: --failfast
|
2009-12-13 17:24:36 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Stops running tests and reports the failure immediately after a test fails.
|
2009-12-13 17:24:36 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --testrunner TESTRUNNER
|
2011-06-10 10:26:05 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Controls the test runner class that is used to execute tests. This value
|
|
|
|
|
overrides the value provided by the :setting:`TEST_RUNNER` setting.
|
Fixed #2879 -- Added support for the integration with Selenium and other in-browser testing frameworks. Also added the first Selenium tests for `contrib.admin`. Many thanks to everyone for their contributions and feedback: Mikeal Rogers, Dirk Datzert, mir, Simon G., Almad, Russell Keith-Magee, Denis Golomazov, devin, robertrv, andrewbadr, Idan Gazit, voidspace, Tom Christie, hjwp2, Adam Nelson, Jannis Leidel, Anssi Kääriäinen, Preston Holmes, Bruno Renié and Jacob Kaplan-Moss.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17241 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2011-12-22 09:33:58 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --liveserver LIVESERVER
|
Fixed #2879 -- Added support for the integration with Selenium and other in-browser testing frameworks. Also added the first Selenium tests for `contrib.admin`. Many thanks to everyone for their contributions and feedback: Mikeal Rogers, Dirk Datzert, mir, Simon G., Almad, Russell Keith-Magee, Denis Golomazov, devin, robertrv, andrewbadr, Idan Gazit, voidspace, Tom Christie, hjwp2, Adam Nelson, Jannis Leidel, Anssi Kääriäinen, Preston Holmes, Bruno Renié and Jacob Kaplan-Moss.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17241 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2011-12-22 09:33:58 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Overrides the default address where the live server (used with
|
|
|
|
|
:class:`~django.test.LiveServerTestCase`) is expected to run from. The default
|
|
|
|
|
value is ``localhost:8081-8179``.
|
2015-02-05 23:02:10 +01:00
|
|
|
|
|
|
|
|
|
.. versionchanged:: 1.9
|
|
|
|
|
|
|
|
|
|
In earlier versions, the default value was ``localhost:8081``.
|
2011-06-10 10:26:05 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --noinput, --no-input
|
|
|
|
|
|
|
|
|
|
Suppresses all user prompts. A typical prompt is a warning about deleting an
|
|
|
|
|
existing test database.
|
|
|
|
|
|
|
|
|
|
.. versionchanged:: 1.9
|
|
|
|
|
|
|
|
|
|
The ``--no-input`` alias was added.
|
|
|
|
|
|
|
|
|
|
Test runner options
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
The ``test`` command receives options on behalf of the specified
|
|
|
|
|
:option:`--testrunner`. These are the options of the default test runner:
|
|
|
|
|
:class:`~django.test.runner.DiscoverRunner`.
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --keepdb, -k
|
2014-05-27 23:13:08 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Preserves the test database between test runs. This has the advantage of
|
|
|
|
|
skipping both the create and destroy actions which can greatly decrease the
|
|
|
|
|
time to run tests, especially those in a large test suite. If the test database
|
|
|
|
|
does not exist, it will be created on the first run and then preserved for each
|
|
|
|
|
subsequent run. Any unapplied migrations will also be applied to the test
|
|
|
|
|
database before running the test suite.
|
2014-05-27 23:13:08 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --reverse, -r
|
2014-11-22 17:59:05 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Sorts test cases in the opposite execution order. This may help in debugging
|
|
|
|
|
the side effects of tests that aren't properly isolated. :ref:`Grouping by test
|
|
|
|
|
class <order-of-tests>` is preserved when using this option.
|
2014-11-22 17:59:05 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --debug-sql, -d
|
2015-01-10 23:52:59 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Enables :ref:`SQL logging <django-db-logger>` for failing tests. If
|
|
|
|
|
``--verbosity`` is ``2``, then queries in passing tests are also output.
|
2015-01-10 23:52:59 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --parallel [N]
|
2015-02-05 20:31:02 +01:00
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.9
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Runs tests in separate parallel processes. Since modern processors have
|
|
|
|
|
multiple cores, this allows running tests significantly faster.
|
2015-02-05 20:31:02 +01:00
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2015-09-10 14:06:06 +02:00
|
|
|
|
Django distributes test cases — :class:`unittest.TestCase` subclasses — to
|
|
|
|
|
subprocesses. If there are fewer test cases than configured processes, Django
|
|
|
|
|
will reduce the number of processes accordingly.
|
|
|
|
|
|
2015-02-09 22:00:09 +01:00
|
|
|
|
Each process gets its own database. You must ensure that different test cases
|
|
|
|
|
don't access the same resources. For instance, test cases that touch the
|
|
|
|
|
filesystem should create a temporary directory for their own use.
|
|
|
|
|
|
2015-02-05 20:31:02 +01:00
|
|
|
|
This option requires the third-party ``tblib`` package to display tracebacks
|
|
|
|
|
correctly:
|
|
|
|
|
|
|
|
|
|
.. code-block:: console
|
|
|
|
|
|
|
|
|
|
$ pip install tblib
|
|
|
|
|
|
2015-09-10 15:41:26 +02:00
|
|
|
|
This feature isn't available on Windows. It doesn't work with the Oracle
|
|
|
|
|
database backend either.
|
2015-08-30 10:50:10 +02:00
|
|
|
|
|
2015-10-06 19:25:14 +02:00
|
|
|
|
If you want to use :mod:`pdb` while debugging tests, you must disable parallel
|
|
|
|
|
execution (``--parallel=1``). You'll see something like ``bdb.BdbQuit`` if you
|
|
|
|
|
don't.
|
|
|
|
|
|
2015-06-05 16:44:12 +02:00
|
|
|
|
.. warning::
|
|
|
|
|
|
|
|
|
|
When test parallelization is enabled and a test fails, Django may be
|
|
|
|
|
unable to display the exception traceback. This can make debugging
|
|
|
|
|
difficult. If you encounter this problem, run the affected test without
|
|
|
|
|
parallelization to see the traceback of the failure.
|
|
|
|
|
|
|
|
|
|
This is a known limitation. It arises from the need to serialize objects
|
|
|
|
|
in order to exchange them between processes. See
|
|
|
|
|
:ref:`python:pickle-picklable` for details.
|
|
|
|
|
|
2015-11-07 14:57:56 +01:00
|
|
|
|
.. option:: --tag TAGS
|
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.10
|
|
|
|
|
|
|
|
|
|
Runs only tests :ref:`marked with the specified tags <topics-tagging-tests>`.
|
|
|
|
|
May be specified multiple times and combined with :option:`test --exclude-tag`.
|
|
|
|
|
|
|
|
|
|
.. option:: --exclude-tag EXCLUDE_TAGS
|
|
|
|
|
|
|
|
|
|
.. versionadded:: 1.10
|
|
|
|
|
|
|
|
|
|
Excludes tests :ref:`marked with the specified tags <topics-tagging-tests>`.
|
|
|
|
|
May be specified multiple times and combined with :option:`test --tag`.
|
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``testserver``
|
|
|
|
|
--------------
|
2007-08-17 01:05:00 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin:: testserver [fixture [fixture ...]]
|
2009-11-12 14:58:32 +01:00
|
|
|
|
|
2013-11-18 19:25:28 +01:00
|
|
|
|
Runs a Django development server (as in :djadmin:`runserver`) using data from
|
|
|
|
|
the given fixture(s).
|
2007-08-17 01:05:00 +02:00
|
|
|
|
|
|
|
|
|
For example, this command::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin testserver mydata.json
|
2007-08-17 01:05:00 +02:00
|
|
|
|
|
|
|
|
|
...would perform the following steps:
|
|
|
|
|
|
2012-12-22 01:59:06 +01:00
|
|
|
|
1. Create a test database, as described in :ref:`the-test-database`.
|
2011-10-14 02:12:01 +02:00
|
|
|
|
2. Populate the test database with fixture data from the given fixtures.
|
2013-11-18 19:25:28 +01:00
|
|
|
|
(For more on fixtures, see the documentation for :djadmin:`loaddata` above.)
|
|
|
|
|
3. Runs the Django development server (as in :djadmin:`runserver`), pointed at
|
2011-10-14 02:12:01 +02:00
|
|
|
|
this newly created test database instead of your production database.
|
2007-08-17 01:05:00 +02:00
|
|
|
|
|
|
|
|
|
This is useful in a number of ways:
|
|
|
|
|
|
2012-12-22 01:59:06 +01:00
|
|
|
|
* When you're writing :doc:`unit tests </topics/testing/overview>` of how your views
|
2011-10-14 02:12:01 +02:00
|
|
|
|
act with certain fixture data, you can use ``testserver`` to interact with
|
|
|
|
|
the views in a Web browser, manually.
|
2007-08-17 01:05:00 +02:00
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* Let's say you're developing your Django application and have a "pristine"
|
|
|
|
|
copy of a database that you'd like to interact with. You can dump your
|
2013-11-18 19:25:28 +01:00
|
|
|
|
database to a fixture (using the :djadmin:`dumpdata` command, explained
|
|
|
|
|
above), then use ``testserver`` to run your Web application with that data.
|
|
|
|
|
With this arrangement, you have the flexibility of messing up your data
|
2011-10-14 02:12:01 +02:00
|
|
|
|
in any way, knowing that whatever data changes you're making are only
|
|
|
|
|
being made to a test database.
|
2007-08-17 01:05:00 +02:00
|
|
|
|
|
2007-09-14 21:17:15 +02:00
|
|
|
|
Note that this server does *not* automatically detect changes to your Python
|
2013-11-18 19:25:28 +01:00
|
|
|
|
source code (as :djadmin:`runserver` does). It does, however, detect changes to
|
2007-09-14 21:17:15 +02:00
|
|
|
|
templates.
|
2007-08-26 01:56:33 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --addrport ADDRPORT
|
2007-09-14 21:17:15 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies a different port, or IP address and port, from the default of
|
|
|
|
|
``127.0.0.1:8000``. This value follows exactly the same format and serves
|
|
|
|
|
exactly the same function as the argument to the :djadmin:`runserver` command.
|
2007-09-14 21:17:15 +02:00
|
|
|
|
|
|
|
|
|
Examples:
|
|
|
|
|
|
|
|
|
|
To run the test server on port 7000 with ``fixture1`` and ``fixture2``::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin testserver --addrport 7000 fixture1 fixture2
|
|
|
|
|
django-admin testserver fixture1 fixture2 --addrport 7000
|
2007-09-14 21:17:15 +02:00
|
|
|
|
|
|
|
|
|
(The above statements are equivalent. We include both of them to demonstrate
|
2007-09-16 18:01:25 +02:00
|
|
|
|
that it doesn't matter whether the options come before or after the fixture
|
|
|
|
|
arguments.)
|
2007-09-14 21:17:15 +02:00
|
|
|
|
|
2007-11-29 19:15:38 +01:00
|
|
|
|
To run on 1.2.3.4:7000 with a ``test`` fixture::
|
2007-09-14 21:17:15 +02:00
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin testserver --addrport 1.2.3.4:7000 test
|
2007-09-14 21:17:15 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --noinput, --no-input
|
|
|
|
|
|
|
|
|
|
Suppresses all user prompts. A typical prompt is a warning about deleting an
|
|
|
|
|
existing test database.
|
|
|
|
|
|
|
|
|
|
.. versionchanged:: 1.9
|
|
|
|
|
|
|
|
|
|
The ``--no-input`` alias was added.
|
2010-06-21 14:09:25 +02:00
|
|
|
|
|
2010-10-23 18:37:51 +02:00
|
|
|
|
Commands provided by applications
|
|
|
|
|
=================================
|
|
|
|
|
|
|
|
|
|
Some commands are only available when the ``django.contrib`` application that
|
|
|
|
|
:doc:`implements </howto/custom-management-commands>` them has been
|
|
|
|
|
:setting:`enabled <INSTALLED_APPS>`. This section describes them grouped by
|
|
|
|
|
their application.
|
|
|
|
|
|
|
|
|
|
``django.contrib.auth``
|
|
|
|
|
-----------------------
|
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``changepassword``
|
|
|
|
|
~~~~~~~~~~~~~~~~~~
|
2010-10-23 18:37:51 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin:: changepassword [<username>]
|
2010-10-23 18:37:51 +02:00
|
|
|
|
|
|
|
|
|
This command is only available if Django's :doc:`authentication system
|
2012-12-28 20:00:11 +01:00
|
|
|
|
</topics/auth/index>` (``django.contrib.auth``) is installed.
|
2010-10-23 18:37:51 +02:00
|
|
|
|
|
2015-05-08 01:41:42 +02:00
|
|
|
|
Allows changing a user's password. It prompts you to enter a new password twice
|
|
|
|
|
for the given user. If the entries are identical, this immediately becomes the
|
|
|
|
|
new password. If you do not supply a user, the command will attempt to change
|
|
|
|
|
the password whose username matches the current user.
|
2010-10-23 18:37:51 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --database DATABASE
|
|
|
|
|
|
|
|
|
|
Specifies the database to query for the user. Defaults to ``default``.
|
2012-03-05 05:17:55 +01:00
|
|
|
|
|
2010-10-23 18:37:51 +02:00
|
|
|
|
Example usage::
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
django-admin changepassword ringo
|
2010-10-23 18:37:51 +02:00
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``createsuperuser``
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~
|
2010-10-23 18:37:51 +02:00
|
|
|
|
|
|
|
|
|
.. django-admin:: createsuperuser
|
|
|
|
|
|
|
|
|
|
This command is only available if Django's :doc:`authentication system
|
2012-12-28 20:00:11 +01:00
|
|
|
|
</topics/auth/index>` (``django.contrib.auth``) is installed.
|
2010-10-23 18:37:51 +02:00
|
|
|
|
|
|
|
|
|
Creates a superuser account (a user who has all permissions). This is
|
2014-06-10 18:22:07 +02:00
|
|
|
|
useful if you need to create an initial superuser account or if you need to
|
|
|
|
|
programmatically generate superuser accounts for your site(s).
|
2010-10-23 18:37:51 +02:00
|
|
|
|
|
|
|
|
|
When run interactively, this command will prompt for a password for
|
|
|
|
|
the new superuser account. When run non-interactively, 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.
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --username USERNAME
|
|
|
|
|
.. django-admin-option:: --email EMAIL
|
2010-10-23 18:37:51 +02:00
|
|
|
|
|
2011-04-01 18:10:22 +02:00
|
|
|
|
The username and email address for the new account can be supplied by
|
2010-10-23 18:37:51 +02:00
|
|
|
|
using the ``--username`` and ``--email`` arguments on the command
|
|
|
|
|
line. If either of those is not supplied, ``createsuperuser`` will prompt for
|
|
|
|
|
it when running interactively.
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --database DATABASE
|
|
|
|
|
|
|
|
|
|
Specifies the database into which the superuser object will be saved.
|
2012-03-05 05:17:55 +01:00
|
|
|
|
|
2014-07-03 20:30:17 +02:00
|
|
|
|
You can subclass the management command and override ``get_input_data()`` if you
|
|
|
|
|
want to customize data input and validation. Consult the source code for
|
|
|
|
|
details on the existing implementation and the method's parameters. For example,
|
|
|
|
|
it could be useful if you have a ``ForeignKey`` in
|
|
|
|
|
:attr:`~django.contrib.auth.models.CustomUser.REQUIRED_FIELDS` and want to
|
|
|
|
|
allow creating an instance instead of entering the primary key of an existing
|
|
|
|
|
instance.
|
|
|
|
|
|
2010-10-23 18:37:51 +02:00
|
|
|
|
``django.contrib.gis``
|
|
|
|
|
----------------------
|
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``ogrinspect``
|
|
|
|
|
~~~~~~~~~~~~~~
|
2010-10-23 18:37:51 +02:00
|
|
|
|
|
|
|
|
|
This command is only available if :doc:`GeoDjango </ref/contrib/gis/index>`
|
|
|
|
|
(``django.contrib.gis``) is installed.
|
|
|
|
|
|
|
|
|
|
Please refer to its :djadmin:`description <ogrinspect>` in the GeoDjango
|
|
|
|
|
documentation.
|
|
|
|
|
|
2012-10-27 11:49:46 +02:00
|
|
|
|
``django.contrib.sessions``
|
|
|
|
|
---------------------------
|
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``clearsessions``
|
|
|
|
|
~~~~~~~~~~~~~~~~~
|
2012-10-27 11:49:46 +02:00
|
|
|
|
|
|
|
|
|
.. django-admin:: clearsessions
|
|
|
|
|
|
|
|
|
|
Can be run as a cron job or directly to clean out expired sessions.
|
|
|
|
|
|
2010-10-23 18:37:51 +02:00
|
|
|
|
``django.contrib.sitemaps``
|
|
|
|
|
---------------------------
|
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``ping_google``
|
|
|
|
|
~~~~~~~~~~~~~~~
|
2010-10-23 18:37:51 +02:00
|
|
|
|
|
|
|
|
|
This command is only available if the :doc:`Sitemaps framework
|
|
|
|
|
</ref/contrib/sitemaps>` (``django.contrib.sitemaps``) is installed.
|
|
|
|
|
|
|
|
|
|
Please refer to its :djadmin:`description <ping_google>` in the Sitemaps
|
|
|
|
|
documentation.
|
|
|
|
|
|
|
|
|
|
``django.contrib.staticfiles``
|
|
|
|
|
------------------------------
|
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``collectstatic``
|
|
|
|
|
~~~~~~~~~~~~~~~~~
|
2010-10-23 18:37:51 +02:00
|
|
|
|
|
|
|
|
|
This command is only available if the :doc:`static files application
|
2013-03-07 20:15:39 +01:00
|
|
|
|
</howto/static-files/index>` (``django.contrib.staticfiles``) is installed.
|
2010-10-23 18:37:51 +02:00
|
|
|
|
|
|
|
|
|
Please refer to its :djadmin:`description <collectstatic>` in the
|
|
|
|
|
:doc:`staticfiles </ref/contrib/staticfiles>` documentation.
|
|
|
|
|
|
2016-01-24 22:26:11 +01:00
|
|
|
|
``findstatic``
|
|
|
|
|
~~~~~~~~~~~~~~
|
2010-10-23 18:37:51 +02:00
|
|
|
|
|
|
|
|
|
This command is only available if the :doc:`static files application
|
2013-03-07 20:15:39 +01:00
|
|
|
|
</howto/static-files/index>` (``django.contrib.staticfiles``) is installed.
|
2010-10-23 18:37:51 +02:00
|
|
|
|
|
|
|
|
|
Please refer to its :djadmin:`description <findstatic>` in the :doc:`staticfiles
|
|
|
|
|
</ref/contrib/staticfiles>` documentation.
|
|
|
|
|
|
2007-09-09 23:57:59 +02:00
|
|
|
|
Default options
|
|
|
|
|
===============
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. program:: None
|
|
|
|
|
|
2010-10-23 18:37:51 +02:00
|
|
|
|
Although some commands may allow their own custom options, every command
|
2007-09-09 23:57:59 +02:00
|
|
|
|
allows for the following options:
|
2006-01-11 03:06:27 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --pythonpath PYTHONPATH
|
2005-10-06 19:22:23 +02:00
|
|
|
|
|
2005-10-06 19:27:13 +02:00
|
|
|
|
Adds the given filesystem path to the Python `import search path`_. If this
|
2014-07-26 13:21:52 +02:00
|
|
|
|
isn't provided, ``django-admin`` will use the ``PYTHONPATH`` environment
|
2005-10-06 19:27:13 +02:00
|
|
|
|
variable.
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
This option is unnecessary in ``manage.py``, because it takes care of setting
|
|
|
|
|
the Python path for you.
|
2006-01-11 03:06:27 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Example usage::
|
2005-10-06 19:22:23 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
django-admin migrate --pythonpath='/home/djangoprojects/myproject'
|
2006-08-31 16:29:47 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. _import search path: http://www.diveintopython.net/getting_to_know_python/everything_is_an_object.html
|
2006-08-31 16:29:47 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --settings SETTINGS
|
2007-04-09 03:44:26 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
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.
|
2006-09-24 10:22:52 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
This option is unnecessary in ``manage.py``, because it uses
|
2008-02-15 12:38:53 +01:00
|
|
|
|
``settings.py`` from the current project by default.
|
2006-09-24 10:22:52 +02:00
|
|
|
|
|
2008-06-19 15:24:39 +02:00
|
|
|
|
Example usage::
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
django-admin migrate --settings=mysite.settings
|
2008-06-19 15:24:39 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --traceback
|
2013-03-09 12:38:45 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Displays a full stack trace when a :exc:`~django.core.management.CommandError`
|
|
|
|
|
is raised. By default, ``django-admin`` will show a simple error message when a
|
|
|
|
|
``CommandError`` occurs and a full stack trace for any other exception.
|
2008-10-02 14:57:13 +02:00
|
|
|
|
|
|
|
|
|
Example usage::
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
django-admin migrate --traceback
|
|
|
|
|
|
|
|
|
|
.. django-admin-option:: --verbosity {0,1,2,3}, --v {0,1,2,3}
|
2008-10-02 14:57:13 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Specifies the amount of notification and debug information that a command
|
|
|
|
|
should print to the console.
|
2008-10-02 14:57:13 +02:00
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* ``0`` means no output.
|
|
|
|
|
* ``1`` means normal output (default).
|
|
|
|
|
* ``2`` means verbose output.
|
|
|
|
|
* ``3`` means *very* verbose output.
|
2008-10-02 14:57:13 +02:00
|
|
|
|
|
2013-02-23 16:28:45 +01:00
|
|
|
|
Example usage::
|
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
django-admin migrate --verbosity 2
|
2009-11-12 14:58:32 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
.. django-admin-option:: --no-color
|
2009-11-12 14:58:32 +01:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Disables colorized command output. Some commands format their output to be
|
|
|
|
|
colorized. For example, errors will be printed to the console in red and SQL
|
|
|
|
|
statements will be syntax highlighted.
|
2015-09-07 15:17:55 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
Example usage::
|
2015-09-07 15:17:55 +02:00
|
|
|
|
|
2016-01-12 02:59:34 +01:00
|
|
|
|
django-admin runserver --no-color
|
2009-11-12 14:58:32 +01:00
|
|
|
|
|
2006-05-02 03:31:56 +02:00
|
|
|
|
Extra niceties
|
|
|
|
|
==============
|
|
|
|
|
|
2009-12-28 07:48:47 +01:00
|
|
|
|
.. _syntax-coloring:
|
|
|
|
|
|
2006-05-02 03:31:56 +02:00
|
|
|
|
Syntax coloring
|
|
|
|
|
---------------
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
The ``django-admin`` / ``manage.py`` commands will use pretty
|
2010-02-23 14:22:05 +01:00
|
|
|
|
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
|
|
|
|
|
another program.
|
2009-12-28 07:48:47 +01:00
|
|
|
|
|
2013-12-03 03:11:59 +01:00
|
|
|
|
Under Windows, the native console doesn't support ANSI escape sequences so by
|
|
|
|
|
default there is no color output. But you can install the `ANSICON`_
|
|
|
|
|
third-party tool, the Django commands will detect its presence and will make
|
|
|
|
|
use of its services to color output just like on Unix-based platforms.
|
|
|
|
|
|
2009-12-28 07:48:47 +01:00
|
|
|
|
The colors used for syntax highlighting can be customized. Django
|
|
|
|
|
ships with three color palettes:
|
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* ``dark``, suited to terminals that show white text on a black
|
|
|
|
|
background. This is the default palette.
|
2009-12-28 07:48:47 +01:00
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* ``light``, suited to terminals that show black text on a white
|
|
|
|
|
background.
|
2009-12-28 07:48:47 +01:00
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* ``nocolor``, which disables syntax highlighting.
|
2009-12-28 07:48:47 +01:00
|
|
|
|
|
|
|
|
|
You select a palette by setting a ``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::
|
|
|
|
|
|
|
|
|
|
export DJANGO_COLORS="light"
|
|
|
|
|
|
|
|
|
|
You can also customize the colors that are used. Django specifies a
|
|
|
|
|
number of roles in which color is used:
|
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* ``error`` - A major error.
|
|
|
|
|
* ``notice`` - A minor error.
|
2015-11-18 00:46:37 +01:00
|
|
|
|
* ``success`` - A success.
|
|
|
|
|
* ``warning`` - A warning.
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* ``sql_field`` - The name of a model field in SQL.
|
|
|
|
|
* ``sql_coltype`` - The type of a model field in SQL.
|
2013-09-06 00:23:48 +02:00
|
|
|
|
* ``sql_keyword`` - An SQL keyword.
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* ``sql_table`` - The name of a model in SQL.
|
|
|
|
|
* ``http_info`` - A 1XX HTTP Informational server response.
|
|
|
|
|
* ``http_success`` - A 2XX HTTP Success server response.
|
|
|
|
|
* ``http_not_modified`` - A 304 HTTP Not Modified server response.
|
|
|
|
|
* ``http_redirect`` - A 3XX HTTP Redirect server response other than 304.
|
|
|
|
|
* ``http_not_found`` - A 404 HTTP Not Found server response.
|
|
|
|
|
* ``http_bad_request`` - A 4XX HTTP Bad Request server response other than 404.
|
|
|
|
|
* ``http_server_error`` - A 5XX HTTP Server Error response.
|
2015-11-18 00:46:37 +01:00
|
|
|
|
* ``migrate_heading`` - A heading in a migrations management command.
|
|
|
|
|
* ``migrate_label`` - A migration name.
|
|
|
|
|
|
|
|
|
|
.. versionchanged:: 1.9
|
|
|
|
|
|
|
|
|
|
``success`` was added.
|
2009-12-28 07:48:47 +01:00
|
|
|
|
|
|
|
|
|
Each of these roles can be assigned a specific foreground and
|
|
|
|
|
background color, from the following list:
|
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* ``black``
|
|
|
|
|
* ``red``
|
|
|
|
|
* ``green``
|
|
|
|
|
* ``yellow``
|
|
|
|
|
* ``blue``
|
|
|
|
|
* ``magenta``
|
|
|
|
|
* ``cyan``
|
|
|
|
|
* ``white``
|
2009-12-28 07:48:47 +01:00
|
|
|
|
|
|
|
|
|
Each of these colors can then be modified by using the following
|
|
|
|
|
display options:
|
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* ``bold``
|
|
|
|
|
* ``underscore``
|
|
|
|
|
* ``blink``
|
|
|
|
|
* ``reverse``
|
|
|
|
|
* ``conceal``
|
2009-12-28 07:48:47 +01:00
|
|
|
|
|
2011-02-15 00:18:30 +01:00
|
|
|
|
A color specification follows one of the following patterns:
|
2009-12-28 07:48:47 +01:00
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* ``role=fg``
|
|
|
|
|
* ``role=fg/bg``
|
|
|
|
|
* ``role=fg,option,option``
|
|
|
|
|
* ``role=fg/bg,option,option``
|
2009-12-28 07:48:47 +01:00
|
|
|
|
|
|
|
|
|
where ``role`` is the name of a valid color role, ``fg`` is the
|
|
|
|
|
foreground color, ``bg`` is the background color and each ``option``
|
|
|
|
|
is one of the color modifying options. Multiple color specifications
|
2015-05-08 01:41:42 +02:00
|
|
|
|
are then separated by a semicolon. For example::
|
2009-12-28 07:48:47 +01:00
|
|
|
|
|
|
|
|
|
export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
|
|
|
|
|
|
|
|
|
|
would specify that errors be displayed using blinking yellow on blue,
|
|
|
|
|
and notices displayed using magenta. All other color roles would be
|
|
|
|
|
left uncolored.
|
|
|
|
|
|
|
|
|
|
Colors can also be specified by extending a base palette. If you put
|
|
|
|
|
a palette name in a color specification, all the colors implied by that
|
|
|
|
|
palette will be loaded. So::
|
|
|
|
|
|
|
|
|
|
export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
|
|
|
|
|
|
|
|
|
|
would specify the use of all the colors in the light color palette,
|
|
|
|
|
*except* for the colors for errors and notices which would be
|
|
|
|
|
overridden as specified.
|
2006-05-02 03:31:56 +02:00
|
|
|
|
|
2014-08-05 14:23:34 +02:00
|
|
|
|
.. _ANSICON: http://adoxa.altervista.org/ansicon/
|
2013-12-03 03:11:59 +01:00
|
|
|
|
|
2006-05-02 03:31:56 +02:00
|
|
|
|
Bash completion
|
|
|
|
|
---------------
|
|
|
|
|
|
|
|
|
|
If you use the Bash shell, consider installing the Django bash completion
|
|
|
|
|
script, which lives in ``extras/django_bash_completion`` in the Django
|
2014-07-26 13:21:52 +02:00
|
|
|
|
distribution. It enables tab-completion of ``django-admin`` and
|
2006-05-02 03:31:56 +02:00
|
|
|
|
``manage.py`` commands, so you can, for instance...
|
|
|
|
|
|
2014-07-26 13:21:52 +02:00
|
|
|
|
* Type ``django-admin``.
|
2011-10-14 02:12:01 +02:00
|
|
|
|
* Press [TAB] to see all available options.
|
|
|
|
|
* Type ``sql``, then [TAB], to see all available options whose names start
|
|
|
|
|
with ``sql``.
|
2007-09-21 18:19:20 +02:00
|
|
|
|
|
2010-08-19 21:27:44 +02:00
|
|
|
|
See :doc:`/howto/custom-management-commands` for how to add customized actions.
|
2010-12-04 21:58:07 +01:00
|
|
|
|
|
|
|
|
|
==========================================
|
|
|
|
|
Running management commands from your code
|
|
|
|
|
==========================================
|
|
|
|
|
|
|
|
|
|
.. function:: django.core.management.call_command(name, *args, **options)
|
|
|
|
|
|
|
|
|
|
To call a management command from code use ``call_command``.
|
|
|
|
|
|
|
|
|
|
``name``
|
2016-03-03 02:12:56 +01:00
|
|
|
|
the name of the command to call or a command object. Passing the name is
|
|
|
|
|
preferred unless the object is required for testing.
|
2010-12-04 21:58:07 +01:00
|
|
|
|
|
|
|
|
|
``*args``
|
2016-03-12 23:44:08 +01:00
|
|
|
|
a list of arguments accepted by the command. Arguments are passed to the
|
|
|
|
|
argument parser, so you can use the same style as you would on the command
|
|
|
|
|
line. For example, ``call_command('flush', 'verbosity=0')``.
|
2010-12-04 21:58:07 +01:00
|
|
|
|
|
|
|
|
|
``**options``
|
2016-03-12 23:44:08 +01:00
|
|
|
|
named options accepted on the command-line. Options are passed to the command
|
|
|
|
|
without triggering the argument parser, which means you'll need to pass the
|
|
|
|
|
correct type. For example, ``call_command('flush', verbosity=0)`` (zero must
|
|
|
|
|
be an integer rather than a string).
|
2010-12-04 21:58:07 +01:00
|
|
|
|
|
|
|
|
|
Examples::
|
|
|
|
|
|
|
|
|
|
from django.core import management
|
2016-03-03 02:12:56 +01:00
|
|
|
|
from django.core.management.commands import loaddata
|
|
|
|
|
|
2010-12-04 21:58:07 +01:00
|
|
|
|
management.call_command('flush', verbosity=0, interactive=False)
|
|
|
|
|
management.call_command('loaddata', 'test_data', verbosity=0)
|
2016-03-03 02:12:56 +01:00
|
|
|
|
management.call_command(loaddata.Command(), 'test_data', verbosity=0)
|
2012-11-07 18:31:14 +01:00
|
|
|
|
|
2013-09-10 14:39:51 +02:00
|
|
|
|
Note that command options that take no arguments are passed as keywords
|
2014-08-09 21:03:19 +02:00
|
|
|
|
with ``True`` or ``False``, as you can see with the ``interactive`` option above.
|
2013-09-10 14:39:51 +02:00
|
|
|
|
|
2014-08-09 21:03:19 +02:00
|
|
|
|
Named arguments can be passed by using either one of the following syntaxes::
|
|
|
|
|
|
|
|
|
|
# Similar to the command line
|
2015-01-18 02:14:45 +01:00
|
|
|
|
management.call_command('dumpdata', '--natural-foreign')
|
2014-08-09 21:03:19 +02:00
|
|
|
|
|
|
|
|
|
# Named argument similar to the command line minus the initial dashes and
|
|
|
|
|
# with internal dashes replaced by underscores
|
2015-01-18 02:14:45 +01:00
|
|
|
|
management.call_command('dumpdata', natural_foreign=True)
|
2014-08-09 21:03:19 +02:00
|
|
|
|
|
2015-01-18 02:14:45 +01:00
|
|
|
|
# `use_natural_foreign_keys` is the option destination variable
|
|
|
|
|
management.call_command('dumpdata', use_natural_foreign_keys=True)
|
2013-09-10 14:39:51 +02:00
|
|
|
|
|
|
|
|
|
Command options which take multiple options are passed a list::
|
|
|
|
|
|
|
|
|
|
management.call_command('dumpdata', exclude=['contenttypes', 'auth'])
|
|
|
|
|
|
2016-02-13 18:14:36 +01:00
|
|
|
|
The return value of the ``call_command()`` function is the same as the return
|
|
|
|
|
value of the ``handle()`` method of the command.
|
|
|
|
|
|
|
|
|
|
.. versionchanged:: 1.10
|
|
|
|
|
|
|
|
|
|
``call_command()`` now returns the value received from the
|
2016-03-03 02:12:56 +01:00
|
|
|
|
``command.handle()`` method. It now also accepts a command object as the
|
|
|
|
|
first argument.
|
2016-02-13 18:14:36 +01:00
|
|
|
|
|
2012-11-07 18:31:14 +01:00
|
|
|
|
Output redirection
|
|
|
|
|
==================
|
|
|
|
|
|
|
|
|
|
Note that you can redirect standard output and error streams as all commands
|
|
|
|
|
support the ``stdout`` and ``stderr`` options. For example, you could write::
|
|
|
|
|
|
2015-12-23 18:08:40 +01:00
|
|
|
|
with open('/path/to/command_output') as f:
|
2012-11-07 18:31:14 +01:00
|
|
|
|
management.call_command('dumpdata', stdout=f)
|