[1.8.x] Fixed #24358 -- Corrected code-block directives for console sessions.
Backport of eba6dff581
from master
This commit is contained in:
parent
1feeefe918
commit
f0780df608
|
@ -24,7 +24,7 @@ The uWSGI wiki describes several `installation procedures`_. Using pip, the
|
|||
Python package manager, you can install any uWSGI version with a single
|
||||
command. For example:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
# Install current stable version.
|
||||
$ pip install uwsgi
|
||||
|
|
|
@ -24,7 +24,7 @@ The ReportLab library is `available on PyPI`_. A `user guide`_ (not
|
|||
coincidentally, a PDF file) is also available for download.
|
||||
You can install ReportLab with ``pip``:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ pip install reportlab
|
||||
|
||||
|
|
|
@ -52,7 +52,7 @@ might want to set up a new environment with all the dependencies first.
|
|||
Exactly which steps you will need to take depends on your installation process.
|
||||
The most convenient way is to use pip_ with the ``--upgrade`` or ``-U`` flag:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ pip install -U Django
|
||||
|
||||
|
@ -74,7 +74,7 @@ warnings are silenced by default. It is useful to turn the warnings on so they
|
|||
are shown in the test output (you can also use the flag if you test your app
|
||||
manually using ``manage.py runserver``):
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python -Wall manage.py test
|
||||
|
||||
|
|
|
@ -51,7 +51,7 @@ Install it
|
|||
Next, run the Django command-line utility to create the database tables
|
||||
automatically:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py migrate
|
||||
|
||||
|
|
|
@ -15,7 +15,7 @@ It'll consist of two parts:
|
|||
We'll assume you have :doc:`Django installed </intro/install>` already. You can
|
||||
tell Django is installed and which version by running the following command:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python -c "import django; print(django.get_version())"
|
||||
|
||||
|
@ -51,7 +51,7 @@ application-specific settings.
|
|||
From the command line, ``cd`` into a directory where you'd like to store your
|
||||
code, then run the following command:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ django-admin startproject mysite
|
||||
|
||||
|
@ -190,7 +190,7 @@ Some of these applications makes use of at least one database table, though,
|
|||
so we need to create the tables in the database before we can use them. To do
|
||||
that, run the following command:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py migrate
|
||||
|
||||
|
@ -217,7 +217,7 @@ The development server
|
|||
Let's verify your Django project works. Change into the outer :file:`mysite` directory, if
|
||||
you haven't already, and run the following commands:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py runserver
|
||||
|
||||
|
@ -255,7 +255,7 @@ It worked!
|
|||
it as a command-line argument. For instance, this command starts the server
|
||||
on port 8080:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py runserver 8080
|
||||
|
||||
|
@ -263,7 +263,7 @@ It worked!
|
|||
listen on all public IPs (useful if you want to show off your work on other
|
||||
computers), use:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py runserver 0.0.0.0:8000
|
||||
|
||||
|
@ -305,7 +305,7 @@ imported as its own top-level module, rather than a submodule of ``mysite``.
|
|||
To create your app, make sure you're in the same directory as :file:`manage.py`
|
||||
and type this command:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py startapp polls
|
||||
|
||||
|
@ -434,7 +434,7 @@ look like this:
|
|||
|
||||
Now Django knows to include the ``polls`` app. Let's run another command:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py makemigrations polls
|
||||
|
||||
|
@ -464,7 +464,7 @@ schema automatically - that's called :djadmin:`migrate`, and we'll come to it in
|
|||
moment - but first, let's see what SQL that migration would run. The
|
||||
:djadmin:`sqlmigrate` command takes migration names and returns their SQL:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py sqlmigrate polls 0001
|
||||
|
||||
|
@ -534,7 +534,7 @@ your project without making migrations or touching the database.
|
|||
|
||||
Now, run :djadmin:`migrate` again to create those model tables in your database:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py migrate
|
||||
Operations to perform:
|
||||
|
@ -580,7 +580,7 @@ Playing with the API
|
|||
Now, let's hop into the interactive Python shell and play around with the free
|
||||
API Django gives you. To invoke the Python shell, use this command:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py shell
|
||||
|
||||
|
|
|
@ -27,7 +27,7 @@ Creating an admin user
|
|||
First we'll need to create a user who can login to the admin site. Run the
|
||||
following command:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py createsuperuser
|
||||
|
||||
|
@ -60,7 +60,7 @@ server and explore it.
|
|||
|
||||
Recall from Tutorial 1 that you start the development server like so:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py runserver
|
||||
|
||||
|
@ -522,7 +522,7 @@ template directory in the source code of Django itself
|
|||
If you have difficulty finding where the Django source files are located
|
||||
on your system, run the following command:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python -c "
|
||||
import sys
|
||||
|
|
|
@ -150,7 +150,7 @@ Unix ``grep`` utility to search for a phrase in all of the documentation. For
|
|||
example, this will show you each mention of the phrase "max_length" in any
|
||||
Django document:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ grep -r max_length /path/to/django/docs/
|
||||
|
||||
|
@ -163,14 +163,14 @@ You can get a local copy of the HTML documentation following a few easy steps:
|
|||
plain text to HTML. You'll need to install Sphinx by either downloading
|
||||
and installing the package from the Sphinx Web site, or with ``pip``:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ pip install Sphinx
|
||||
|
||||
* Then, just use the included ``Makefile`` to turn the documentation into
|
||||
HTML:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ cd path/to/django/docs
|
||||
$ make html
|
||||
|
|
|
@ -58,7 +58,7 @@ __ http://www.gaia-gis.it/gaia-sins/
|
|||
On Debian/Ubuntu, you are advised to install the following packages which will
|
||||
install, directly or by dependency, the required geospatial libraries:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ sudo apt-get install binutils libproj-dev gdal-bin
|
||||
|
||||
|
|
|
@ -56,7 +56,7 @@ First, create a spatial database for your project.
|
|||
If you are using PostGIS, create the database from the :ref:`spatial database
|
||||
template <spatialdb_template>`:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ createdb -T template_postgis geodjango
|
||||
|
||||
|
@ -66,7 +66,7 @@ template <spatialdb_template>`:
|
|||
create a database. To create a user with ``CREATE DATABASE`` privileges in
|
||||
PostgreSQL, use the following commands:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ sudo su - postgres
|
||||
$ createuser --createdb geo
|
||||
|
@ -84,14 +84,14 @@ Create a New Project
|
|||
Use the standard ``django-admin`` script to create a project called
|
||||
``geodjango``:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ django-admin startproject geodjango
|
||||
|
||||
This will initialize a new project. Now, create a ``world`` Django application
|
||||
within the ``geodjango`` project:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ cd geodjango
|
||||
$ python manage.py startapp world
|
||||
|
@ -137,7 +137,7 @@ The world borders data is available in this `zip file`__. Create a ``data``
|
|||
directory in the ``world`` application, download the world borders data, and
|
||||
unzip. On GNU/Linux platforms, use the following commands:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ mkdir world/data
|
||||
$ cd world/data
|
||||
|
@ -166,7 +166,7 @@ Use ``ogrinfo`` to examine spatial data
|
|||
The GDAL ``ogrinfo`` utility allows examining the metadata of shapefiles or
|
||||
other vector data sources:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ ogrinfo world/data/TM_WORLD_BORDERS-0.3.shp
|
||||
INFO: Open of `world/data/TM_WORLD_BORDERS-0.3.shp'
|
||||
|
@ -177,7 +177,7 @@ other vector data sources:
|
|||
layer contains polygon data. To find out more, we'll specify the layer name
|
||||
and use the ``-so`` option to get only the important summary information:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ ogrinfo -so world/data/TM_WORLD_BORDERS-0.3.shp TM_WORLD_BORDERS-0.3
|
||||
INFO: Open of `world/data/TM_WORLD_BORDERS-0.3.shp'
|
||||
|
@ -267,7 +267,7 @@ Run ``migrate``
|
|||
After defining your model, you need to sync it with the database. First,
|
||||
create a database migration:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py makemigrations
|
||||
Migrations for 'world':
|
||||
|
@ -277,7 +277,7 @@ create a database migration:
|
|||
Let's look at the SQL that will generate the table for the ``WorldBorder``
|
||||
model:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py sqlmigrate world 0001
|
||||
|
||||
|
@ -314,7 +314,7 @@ This command should produce the following output:
|
|||
If this looks correct, run :djadmin:`migrate` to create this table in the
|
||||
database:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py migrate
|
||||
Operations to perform:
|
||||
|
@ -351,7 +351,7 @@ library that can work with all the vector data sources that OGR supports.
|
|||
|
||||
First, invoke the Django shell:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py shell
|
||||
|
||||
|
@ -515,7 +515,7 @@ A few notes about what's going on:
|
|||
|
||||
Afterwards, invoke the Django shell from the ``geodjango`` project directory:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py shell
|
||||
|
||||
|
@ -537,7 +537,7 @@ and generates a model definition and ``LayerMapping`` dictionary automatically.
|
|||
|
||||
The general usage of the command goes as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py ogrinspect [options] <data_source> <model_name> [options]
|
||||
|
||||
|
@ -548,7 +548,7 @@ be used to further define how the model is generated.
|
|||
For example, the following command nearly reproduces the ``WorldBorder`` model
|
||||
and mapping dictionary created above, automatically:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py ogrinspect world/data/TM_WORLD_BORDERS-0.3.shp WorldBorder \
|
||||
--srid=4326 --mapping --multi
|
||||
|
@ -609,7 +609,7 @@ GeoDjango adds spatial lookups to the Django ORM. For example, you
|
|||
can find the country in the ``WorldBorder`` table that contains
|
||||
a particular point. First, fire up the management shell:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py shell
|
||||
|
||||
|
@ -753,13 +753,13 @@ Next, edit your ``urls.py`` in the ``geodjango`` application folder as follows::
|
|||
|
||||
Create an admin user:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py createsuperuser
|
||||
|
||||
Next, start up the Django development server:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ python manage.py runserver
|
||||
|
||||
|
|
|
@ -47,7 +47,7 @@ be consistent, but any example can use ``manage.py`` just as well.
|
|||
Usage
|
||||
=====
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ django-admin <command> [options]
|
||||
$ manage.py <command> [options]
|
||||
|
|
|
@ -556,7 +556,7 @@ need to reload your data. Do this after you have made the change to using
|
|||
To upgrade each application to use a ``DecimalField``, you can do the
|
||||
following, replacing ``<app>`` in the code below with each app's name:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ ./manage.py dumpdata --format=xml <app> > data-dump.xml
|
||||
$ ./manage.py reset <app>
|
||||
|
@ -685,13 +685,13 @@ Subcommands must now precede options
|
|||
``django-admin.py`` and ``manage.py`` now require subcommands to precede
|
||||
options. So:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ django-admin.py --settings=foo.bar runserver
|
||||
|
||||
...no longer works and should be changed to:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ django-admin.py runserver --settings=foo.bar
|
||||
|
||||
|
|
|
@ -34,7 +34,7 @@ but may not be mandatory depending on your particular database backend,
|
|||
operating system and time zone. If you encounter an exception querying dates
|
||||
or times, please try installing it before filing a bug. It's as simple as:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ pip install pytz
|
||||
|
||||
|
|
|
@ -140,9 +140,9 @@ uninstalling is as simple as deleting the ``django`` directory from your Python
|
|||
``site-packages``. To find the directory you need to remove, you can run the
|
||||
following at your shell prompt (not the interactive Python prompt):
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
python -c "import sys; sys.path = sys.path[1:]; import django; print(django.__path__)"
|
||||
$ python -c "import sys; sys.path = sys.path[1:]; import django; print(django.__path__)"
|
||||
|
||||
|
||||
.. _install-django-code:
|
||||
|
@ -256,18 +256,18 @@ latest bug fixes and improvements, follow these instructions:
|
|||
2. Check out Django's main development branch (the 'trunk' or 'master') like
|
||||
so:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
git clone git://github.com/django/django.git django-trunk
|
||||
$ git clone git://github.com/django/django.git django-trunk
|
||||
|
||||
This will create a directory ``django-trunk`` in your current directory.
|
||||
|
||||
3. Make sure that the Python interpreter can load Django's code. The most
|
||||
convenient way to do this is via pip_. Run the following command:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
sudo pip install -e django-trunk/
|
||||
$ sudo pip install -e django-trunk/
|
||||
|
||||
(If using a virtualenv_ you can omit ``sudo``.)
|
||||
|
||||
|
@ -302,9 +302,9 @@ with a checkout of Django's latest code in it. Then add a ``.pth`` file
|
|||
containing the full path to the ``django-trunk`` directory to your system's
|
||||
``site-packages`` directory. For example, on a Unix-like system:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
echo WORKING-DIR/django-trunk > SITE-PACKAGES-DIR/django.pth
|
||||
$ echo WORKING-DIR/django-trunk > SITE-PACKAGES-DIR/django.pth
|
||||
|
||||
In the above line, change ``WORKING-DIR/django-trunk`` to match the full path
|
||||
to your new ``django-trunk`` directory, and change ``SITE-PACKAGES-DIR`` to
|
||||
|
@ -314,9 +314,9 @@ The location of the ``site-packages`` directory depends on the operating
|
|||
system, and the location in which Python was installed. To find your system's
|
||||
``site-packages`` location, execute the following:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())"
|
||||
$ python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())"
|
||||
|
||||
(Note that this should be run from a shell prompt, not a Python interactive
|
||||
prompt.)
|
||||
|
@ -334,9 +334,9 @@ On Unix-like systems, create a symbolic link to the file
|
|||
``django-trunk/django/bin/django-admin`` in a directory on your system
|
||||
path, such as ``/usr/local/bin``. For example:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
ln -s WORKING-DIR/django-trunk/django/bin/django-admin.py /usr/local/bin/
|
||||
$ ln -s WORKING-DIR/django-trunk/django/bin/django-admin.py /usr/local/bin/
|
||||
|
||||
(In the above line, change WORKING-DIR to match the full path to your new
|
||||
``django-trunk`` directory.)
|
||||
|
|
|
@ -766,9 +766,9 @@ to change the default address (in the case, for example, where the 8081 port is
|
|||
already taken) then you may pass a different one to the :djadmin:`test` command
|
||||
via the :djadminopt:`--liveserver` option, for example:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
./manage.py test --liveserver=localhost:8082
|
||||
$ ./manage.py test --liveserver=localhost:8082
|
||||
|
||||
Another way of changing the default server address is by setting the
|
||||
`DJANGO_LIVE_TEST_SERVER_ADDRESS` environment variable somewhere in your
|
||||
|
@ -784,9 +784,9 @@ tests might randomly fail with an "Address already in use" error. To avoid this
|
|||
problem, you can pass a comma-separated list of ports or ranges of ports (at
|
||||
least as many as the number of potential parallel processes). For example:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
./manage.py test --liveserver=localhost:8082,8090-8100,9000-9200,7041
|
||||
$ ./manage.py test --liveserver=localhost:8082,8090-8100,9000-9200,7041
|
||||
|
||||
Then, during test execution, each new live test server will try every specified
|
||||
port until it finds one that is free and takes it.
|
||||
|
@ -797,9 +797,9 @@ To demonstrate how to use ``LiveServerTestCase``, let's write a simple Selenium
|
|||
test. First of all, you need to install the `selenium package`_ into your
|
||||
Python path:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
pip install selenium
|
||||
$ pip install selenium
|
||||
|
||||
Then, add a ``LiveServerTestCase``-based test to your app's tests module
|
||||
(for example: ``myapp/tests.py``). The code for this test may look as follows::
|
||||
|
@ -830,9 +830,9 @@ Then, add a ``LiveServerTestCase``-based test to your app's tests module
|
|||
|
||||
Finally, you may run the test as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
./manage.py test myapp.tests.MySeleniumTests.test_login
|
||||
$ ./manage.py test myapp.tests.MySeleniumTests.test_login
|
||||
|
||||
This example will automatically open Firefox then go to the login page, enter
|
||||
the credentials and press the "Log in" button. Selenium offers other drivers in
|
||||
|
|
Loading…
Reference in New Issue