Unified listing of shell commands/code
- use code-block:: bash - prefix the command with $
This commit is contained in:
parent
0dd9075622
commit
80027d2c38
|
@ -54,7 +54,7 @@ The most convenient way is to use pip_ with the ``--upgrade`` or ``-U`` flag:
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
pip install -U Django
|
||||
$ pip install -U Django
|
||||
|
||||
pip_ also automatically uninstalls the previous version of Django.
|
||||
|
||||
|
|
|
@ -30,15 +30,17 @@ sample settings module that uses the SQLite database. To run the tests:
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
git clone git@github.com:django/django.git django-repo
|
||||
cd django-repo/tests
|
||||
PYTHONPATH=..:$PYTHONPATH ./runtests.py
|
||||
$ git clone git@github.com:django/django.git django-repo
|
||||
$ cd django-repo/tests
|
||||
$ PYTHONPATH=..:$PYTHONPATH ./runtests.py
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
Older versions of Django required specifying a settings file::
|
||||
Older versions of Django required specifying a settings file:
|
||||
|
||||
PYTHONPATH=..:$PYTHONPATH python ./runtests.py --settings=test_sqlite
|
||||
.. code-block:: bash
|
||||
|
||||
$ PYTHONPATH=..:$PYTHONPATH python ./runtests.py --settings=test_sqlite
|
||||
|
||||
``runtests.py`` now uses ``test_sqlite`` by default if settings aren't provided
|
||||
through either ``--settings`` or :envvar:`DJANGO_SETTINGS_MODULE`.
|
||||
|
@ -111,7 +113,7 @@ internationalization, type:
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
./runtests.py --settings=path.to.settings generic_relations i18n
|
||||
$ ./runtests.py --settings=path.to.settings generic_relations i18n
|
||||
|
||||
How do you find out the names of individual tests? Look in ``tests/`` — each
|
||||
directory name there is the name of a test. Contrib app names are also valid
|
||||
|
@ -123,13 +125,13 @@ of the ``i18n`` module, type:
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
./runtests.py --settings=path.to.settings i18n.tests.TranslationTests
|
||||
$ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests
|
||||
|
||||
Going beyond that, you can specify an individual test method like this:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
./runtests.py --settings=path.to.settings i18n.tests.TranslationTests.test_lazy_objects
|
||||
$ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests.test_lazy_objects
|
||||
|
||||
Running the Selenium tests
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
@ -141,7 +143,7 @@ the tests with the ``--selenium`` option:
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
./runtests.py --settings=test_sqlite --selenium admin_inlines
|
||||
$ ./runtests.py --settings=test_sqlite --selenium admin_inlines
|
||||
|
||||
|
||||
.. _running-unit-tests-dependencies:
|
||||
|
@ -165,9 +167,11 @@ dependencies:
|
|||
|
||||
You can find these dependencies in `pip requirements files`_ inside the
|
||||
``tests/requirements`` directory of the Django source tree and install them
|
||||
like so::
|
||||
like so:
|
||||
|
||||
pip install -r tests/requirements/py2.txt # Python 3: py3.txt
|
||||
.. code-block:: bash
|
||||
|
||||
$ pip install -r tests/requirements/py2.txt # Python 3: py3.txt
|
||||
|
||||
You can also install the database adapter(s) of your choice using
|
||||
``oracle.txt``, ``mysql.txt``, or ``postgres.txt``.
|
||||
|
@ -200,13 +204,17 @@ Contributors are encouraged to run coverage on the test suite to identify areas
|
|||
that need additional tests. The coverage tool installation and use is described
|
||||
in :ref:`testing code coverage<topics-testing-code-coverage>`.
|
||||
|
||||
To run coverage on the Django test suite using the standard test settings::
|
||||
To run coverage on the Django test suite using the standard test settings:
|
||||
|
||||
coverage run ./runtests.py --settings=test_sqlite
|
||||
.. code-block:: bash
|
||||
|
||||
After running coverage, generate the html report by running::
|
||||
$ coverage run ./runtests.py --settings=test_sqlite
|
||||
|
||||
coverage html
|
||||
After running coverage, generate the html report by running:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ coverage html
|
||||
|
||||
When running coverage for the Django tests, the included ``.coveragerc``
|
||||
settings file defines ``coverage_html`` as the output directory for the report
|
||||
|
@ -225,6 +233,8 @@ multiple modules by using a ``tests`` directory in the normal Python way.
|
|||
If you have URLs that need to be mapped, put them in ``tests/urls.py``.
|
||||
|
||||
To run tests for just one contrib app (e.g. ``auth``), use the same
|
||||
method as above::
|
||||
method as above:
|
||||
|
||||
./runtests.py --settings=settings django.contrib.auth
|
||||
.. code-block:: bash
|
||||
|
||||
$ ./runtests.py --settings=settings django.contrib.auth
|
||||
|
|
|
@ -17,7 +17,7 @@ tell Django is installed and which version by running the following command:
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
python -c "import django; print(django.get_version())"
|
||||
$ python -c "import django; print(django.get_version())"
|
||||
|
||||
If Django is installed, you should see the version of your installation. If it
|
||||
isn't, you'll get an error telling "No module named django".
|
||||
|
@ -55,7 +55,7 @@ code, then run the following command:
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
django-admin.py startproject mysite
|
||||
$ django-admin.py startproject mysite
|
||||
|
||||
This will create a ``mysite`` directory in your current directory. If it didn't
|
||||
work, see :ref:`troubleshooting-django-admin-py`.
|
||||
|
@ -131,8 +131,13 @@ The development server
|
|||
----------------------
|
||||
|
||||
Let's verify this worked. Change into the outer :file:`mysite` directory, if
|
||||
you haven't already, and run the command ``python manage.py runserver``. You'll
|
||||
see the following output on the command line:
|
||||
you haven't already, and run the command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ python manage.py runserver
|
||||
|
||||
You'll see the following output on the command line:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|
@ -568,9 +573,11 @@ make new ones - it specialises in upgrading your database live, without
|
|||
losing data. We'll cover them in more depth in a later part of the tutorial,
|
||||
but for now, remember the three-step guide to making model changes:
|
||||
|
||||
* Change your models (in models.py)
|
||||
* Run ``python manage.py makemigrations`` to create migrations for those changes
|
||||
* Run ``python manage.py migrate`` to apply those changes to the database.
|
||||
* Change your models (in ``models.py``).
|
||||
* Run :djadmin:`python manage.py makemigrations <makemigrations>` to create
|
||||
migrations for those changes
|
||||
* Run :djadmin:`python manage.py migrate <migrate>` to apply those changes to
|
||||
the database.
|
||||
|
||||
The reason there's separate commands to make and apply migrations is because
|
||||
you'll commit migrations to your version control system and ship them with
|
||||
|
|
|
@ -469,7 +469,7 @@ template directory in the source code of Django itself
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
python -c "
|
||||
$ python -c "
|
||||
import sys
|
||||
sys.path = sys.path[1:]
|
||||
import django
|
||||
|
|
|
@ -38,8 +38,8 @@ Usage
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
django-admin.py <command> [options]
|
||||
manage.py <command> [options]
|
||||
$ django-admin.py <command> [options]
|
||||
$ manage.py <command> [options]
|
||||
|
||||
``command`` should be one of the commands listed in this document.
|
||||
``options``, which is optional, should be zero or more of the options available
|
||||
|
|
Loading…
Reference in New Issue