<commit_before>=============================
django-admin.py and manage.py
=============================

``django-admin.py`` is Django's command-line utility for administrative tasks.
This document outlines all it can do.

In addition, ``manage.py`` is automatically created in each Django project.
``manage.py`` is a thin wrapper around ``django-admin.py`` that takes care of
two things for you before delegating to ``django-admin.py``:

    * It puts your project's package on ``sys.path``.

    * It sets the ``DJANGO_SETTINGS_MODULE`` environment variable so that it
      points to your project's ``settings.py`` file.

The ``django-admin.py`` script should be on your system path if you installed
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
symlinking it from some place on your path, such as ``/usr/local/bin``.

For Windows users, who do not have symlinking functionality available, you
can copy ``django-admin.py`` to a location on your existing path or edit the
``PATH`` settings (under ``Settings - Control Panel - System - Advanced - Environment...``)
to point to its installed location.

Generally, when working on a single Django project, it's easier to use
``manage.py``. Use ``django-admin.py`` with ``DJANGO_SETTINGS_MODULE``, or the
``--settings`` command line option, if you need to switch between multiple
Django settings files.

The command-line examples throughout this document use ``django-admin.py`` to
be consistent, but any example can use ``manage.py`` just as well.

Usage
=====

``django-admin.py <subcommand> [options]``

``manage.py <subcommand> [options]``

``subcommand`` should be one of the subcommands listed in this document.
``options``, which is optional, should be zero or more of the options available
for the given subcommand.

Getting runtime help
--------------------

In Django 0.96, run ``django-admin.py --help`` to display a help message that
includes a terse list of all available subcommands and options.

In the Django development version, run ``django-admin.py help`` to display a
list of all available subcommands. Run ``django-admin.py help <subcommand>``
to display a description of the given subcommand and a list of its available
options.

App names
---------

Many subcommands take a list of "app names." An "app name" is the basename of
the package containing your models. For example, if your ``INSTALLED_APPS``
contains the string ``'mysite.blog'``, the app name is ``blog``.

Determining the version
-----------------------

Run ``django-admin.py --version`` to display the current Django version.

Examples of output::

	0.95
    0.96
    0.97-pre-SVN-6069

Available subcommands
=====================

adminindex <appname appname ...>
--------------------------------

Prints the admin-index template snippet for the given app name(s).

Use admin-index template snippets if you want to customize the look and feel of
your admin's index page. See `Tutorial 2`_ for more information.

.. _Tutorial 2: ../tutorial02/

createcachetable <tablename>
----------------------------

Creates a cache table named ``tablename`` for use with the database cache
backend. See the `cache documentation`_ for more information.

.. _cache documentation: ../cache/

dbshell
-------

Runs the command-line client for the database engine specified in your
``DATABASE_ENGINE`` setting, with the connection parameters specified in your
``DATABASE_USER``, ``DATABASE_PASSWORD``, etc., settings.

    * 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.

This command assumes the programs are on your ``PATH`` so that a simple call to
the program name (``psql``, ``mysql``, ``sqlite3``) will find the program in
the right place. There's no way to specify the location of the program
manually.

diffsettings
------------

Displays differences between the current settings file and Django's default
settings.

Settings that don't appear in the defaults are followed by ``"###"``. For
example, the default settings don't define ``ROOT_URLCONF``, so
``ROOT_URLCONF`` is followed by ``"###"`` in the output of ``diffsettings``.

Note that Django's default settings live in ``django/conf/global_settings.py``,
if you're ever curious to see the full list of defaults.

dumpdata <appname appname ...>
------------------------------

Outputs to standard output all data in the database associated with the named
application(s).

If no application name is provided, all installed applications will be dumped.

The output of ``dumpdata`` can be used as input for ``loaddata``.

Note that ``dumpdata`` uses the default manager on the mdoel for selecting the
records to dump. If you're using a `custom manager`_ as the default manager
and it filters some of the available records, not all of the objects will be
dumped.

.. _custom manager: ../model-api/#custom-managers

--format
~~~~~~~~

By default, ``dumpdata`` will format its output in JSON, but you can use the
``--format`` option to specify another format. Currently supported formats are
listed in `Serialization formats`_.

Example usage::

    django-admin.py dumpdata --format=xml

.. _Serialization formats: ../serialization/#serialization-formats

--indent
~~~~~~~~

By default, ``dumpdata`` will output all data on a single line. This isn't easy
for humans to read, so you can use the ``--indent`` option to pretty-print the
output with a number of indentation spaces.

Example usage::

    django-admin.py dumpdata --indent=4
<commit_msg>Typo fix.<commit_after>=============================
django-admin.py and manage.py
=============================

``django-admin.py`` is Django's command-line utility for administrative tasks.
This document outlines all it can do.

In addition, ``manage.py`` is automatically created in each Django project.
``manage.py`` is a thin wrapper around ``django-admin.py`` that takes care of
two things for you before delegating to ``django-admin.py``:

    * It puts your project's package on ``sys.path``.

    * It sets the ``DJANGO_SETTINGS_MODULE`` environment variable so that it
      points to your project's ``settings.py`` file.

The ``django-admin.py`` script should be on your system path if you installed
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
symlinking it from some place on your path, such as ``/usr/local/bin``.

For Windows users, who do not have symlinking functionality available, you
can copy ``django-admin.py`` to a location on your existing path or edit the
``PATH`` settings (under ``Settings - Control Panel - System - Advanced - Environment...``)
to point to its installed location.

Generally, when working on a single Django project, it's easier to use
``manage.py``. Use ``django-admin.py`` with ``DJANGO_SETTINGS_MODULE``, or the
``--settings`` command line option, if you need to switch between multiple
Django settings files.

The command-line examples throughout this document use ``django-admin.py`` to
be consistent, but any example can use ``manage.py`` just as well.

Usage
=====

``django-admin.py <subcommand> [options]``

``manage.py <subcommand> [options]``

``subcommand`` should be one of the subcommands listed in this document.
``options``, which is optional, should be zero or more of the options available
for the given subcommand.

Getting runtime help
--------------------

In Django 0.96, run ``django-admin.py --help`` to display a help message that
includes a terse list of all available subcommands and options.

In the Django development version, run ``django-admin.py help`` to display a
list of all available subcommands. Run ``django-admin.py help <subcommand>``
to display a description of the given subcommand and a list of its available
options.

App names
---------

Many subcommands take a list of "app names." An "app name" is the basename of
the package containing your models. For example, if your ``INSTALLED_APPS``
contains the string ``'mysite.blog'``, the app name is ``blog``.

Determining the version
-----------------------

Run ``django-admin.py --version`` to display the current Django version.

Examples of output::

	0.95
    0.96
    0.97-pre-SVN-6069

Available subcommands
=====================

adminindex <appname appname ...>
--------------------------------

Prints the admin-index template snippet for the given app name(s).

Use admin-index template snippets if you want to customize the look and feel of
your admin's index page. See `Tutorial 2`_ for more information.

.. _Tutorial 2: ../tutorial02/

createcachetable <tablename>
----------------------------

Creates a cache table named ``tablename`` for use with the database cache
backend. See the `cache documentation`_ for more information.

.. _cache documentation: ../cache/

dbshell
-------

Runs the command-line client for the database engine specified in your
``DATABASE_ENGINE`` setting, with the connection parameters specified in your
``DATABASE_USER``, ``DATABASE_PASSWORD``, etc., settings.

    * 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.

This command assumes the programs are on your ``PATH`` so that a simple call to
the program name (``psql``, ``mysql``, ``sqlite3``) will find the program in
the right place. There's no way to specify the location of the program
manually.

diffsettings
------------

Displays differences between the current settings file and Django's default
settings.

Settings that don't appear in the defaults are followed by ``"###"``. For
example, the default settings don't define ``ROOT_URLCONF``, so
``ROOT_URLCONF`` is followed by ``"###"`` in the output of ``diffsettings``.

Note that Django's default settings live in ``django/conf/global_settings.py``,
if you're ever curious to see the full list of defaults.

dumpdata <appname appname ...>
------------------------------

Outputs to standard output all data in the database associated with the named
application(s).

If no application name is provided, all installed applications will be dumped.

The output of ``dumpdata`` can be used as input for ``loaddata``.

Note that ``dumpdata`` uses the default manager on the model for selecting the
records to dump. If you're using a `custom manager`_ as the default manager
and it filters some of the available records, not all of the objects will be
dumped.

.. _custom manager: ../model-api/#custom-managers

--format
~~~~~~~~

By default, ``dumpdata`` will format its output in JSON, but you can use the
``--format`` option to specify another format. Currently supported formats are
listed in `Serialization formats`_.

Example usage::

    django-admin.py dumpdata --format=xml

.. _Serialization formats: ../serialization/#serialization-formats

--indent
~~~~~~~~

By default, ``dumpdata`` will output all data on a single line. This isn't easy
for humans to read, so you can use the ``--indent`` option to pretty-print the
output with a number of indentation spaces.

Example usage::

    django-admin.py dumpdata --indent=4

{'fraction_non_alphanumeric': 0.13629955947136563, 'fraction_numerical': 0.004052863436123348, 'mean_word_length': 3.76732465350693, 'pattern_counts': {'":': 0, '<': 15, '<?xml version=': 0, '>': 15, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 2}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5247443', 'n_tokens_mistral': 3097, 'n_tokens_neox': 2962, 'n_words': 1469}