From eba6dff581aa8bd6a1c08456e83e68ad09ae4ec3 Mon Sep 17 00:00:00 2001 From: Sean Wang Date: Wed, 18 Feb 2015 19:19:21 -0800 Subject: [PATCH] Fixed #24358 -- Corrected code-block directives for console sessions. --- docs/howto/deployment/wsgi/uwsgi.txt | 2 +- docs/howto/outputting-pdf.txt | 2 +- docs/howto/upgrade-version.txt | 4 +- .../writing-code/coding-style.txt | 2 +- .../contributing/writing-code/unit-tests.txt | 58 +++++-------------- docs/internals/howto-release-django.txt | 44 ++++++-------- docs/intro/overview.txt | 2 +- docs/intro/tutorial01.txt | 22 +++---- docs/intro/tutorial02.txt | 6 +- docs/intro/whatsnext.txt | 6 +- docs/ref/contrib/gis/install/geolibs.txt | 2 +- docs/ref/contrib/gis/tutorial.txt | 34 +++++------ docs/ref/django-admin.txt | 2 +- docs/releases/1.0-porting-guide.txt | 6 +- docs/topics/i18n/timezones.txt | 2 +- docs/topics/install.txt | 24 ++++---- docs/topics/testing/tools.txt | 16 ++--- 17 files changed, 100 insertions(+), 134 deletions(-) diff --git a/docs/howto/deployment/wsgi/uwsgi.txt b/docs/howto/deployment/wsgi/uwsgi.txt index 0afb57b9bd..89eb9b5698 100644 --- a/docs/howto/deployment/wsgi/uwsgi.txt +++ b/docs/howto/deployment/wsgi/uwsgi.txt @@ -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 diff --git a/docs/howto/outputting-pdf.txt b/docs/howto/outputting-pdf.txt index 4bc413e009..31ed83fa84 100644 --- a/docs/howto/outputting-pdf.txt +++ b/docs/howto/outputting-pdf.txt @@ -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 diff --git a/docs/howto/upgrade-version.txt b/docs/howto/upgrade-version.txt index 82666d677b..3c9c1b8d78 100644 --- a/docs/howto/upgrade-version.txt +++ b/docs/howto/upgrade-version.txt @@ -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 diff --git a/docs/internals/contributing/writing-code/coding-style.txt b/docs/internals/contributing/writing-code/coding-style.txt index 7275393888..2aa967c88d 100644 --- a/docs/internals/contributing/writing-code/coding-style.txt +++ b/docs/internals/contributing/writing-code/coding-style.txt @@ -48,7 +48,7 @@ Imports Quick start: - .. code-block:: bash + .. code-block:: console $ pip install isort $ isort -rc . diff --git a/docs/internals/contributing/writing-code/unit-tests.txt b/docs/internals/contributing/writing-code/unit-tests.txt index e205092177..4934b40a81 100644 --- a/docs/internals/contributing/writing-code/unit-tests.txt +++ b/docs/internals/contributing/writing-code/unit-tests.txt @@ -2,6 +2,8 @@ Unit tests ========== +.. highlight:: console + Django comes with a test suite of its own, in the ``tests`` directory of the code base. It's our policy to make sure all tests pass at all times. @@ -26,9 +28,7 @@ the other optional test dependencies. Running the tests requires a Django settings module that defines the databases to use. To make it easy to get started, Django provides and uses a -sample settings module that uses the SQLite database. To run the tests: - -.. code-block:: bash +sample settings module that uses the SQLite database. To run the tests:: $ git clone https://github.com/django/django.git django-repo $ cd django-repo/tests @@ -96,9 +96,7 @@ tests by appending the names of the test modules to ``runtests.py`` on the command line. For example, if you'd like to run tests only for generic relations and -internationalization, type: - -.. code-block:: bash +internationalization, type:: $ ./runtests.py --settings=path.to.settings generic_relations i18n @@ -107,15 +105,11 @@ directory name there is the name of a test. If you just want to run a particular class of tests, you can specify a list of paths to individual test classes. For example, to run the ``TranslationTests`` -of the ``i18n`` module, type: - -.. code-block:: bash +of the ``i18n`` module, type:: $ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests -Going beyond that, you can specify an individual test method like this: - -.. code-block:: bash +Going beyond that, you can specify an individual test method like this:: $ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests.test_lazy_objects @@ -125,9 +119,7 @@ Running the Selenium tests Some tests require Selenium and a Web browser (Firefox, Google Chrome, or Internet Explorer). To allow those tests to be run rather than skipped, you must install the selenium_ package into your Python path and run the tests with the -``--selenium`` option: - -.. code-block:: bash +``--selenium`` option:: $ ./runtests.py --settings=test_sqlite --selenium admin_inlines @@ -154,9 +146,7 @@ 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: - -.. code-block:: bash +like so:: $ pip install -r tests/requirements/py3.txt # Python 2: py2.txt @@ -193,15 +183,11 @@ 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`. -To run coverage on the Django test suite using the standard test settings: - -.. code-block:: bash +To run coverage on the Django test suite using the standard test settings:: $ coverage run ./runtests.py --settings=test_sqlite -After running coverage, generate the html report by running: - -.. code-block:: bash +After running coverage, generate the html report by running:: $ coverage html @@ -230,9 +216,7 @@ Many test failures with ``UnicodeEncodeError`` If the ``locales`` package is not installed, some tests will fail with a ``UnicodeEncodeError``. -You can resolve this on Debian-based systems, for example, by running: - -.. code-block:: bash +You can resolve this on Debian-based systems, for example, by running:: $ apt-get install locales $ dpkg-reconfigure locales @@ -249,9 +233,7 @@ it possible to identify a small number of tests that may be related to the failure. For example, suppose that the failing test that works on its own is -``ModelTest.test_eq``, then using: - -.. code-block:: bash +``ModelTest.test_eq``, then using:: $ ./runtests.py --bisect basic.tests.ModelTest.test_eq @@ -265,9 +247,7 @@ failing tests is minimized. The ``--pair`` option runs the given test alongside every other test from the suite, letting you check if another test has side-effects that cause the -failure. So: - -.. code-block:: bash +failure. So:: $ ./runtests.py --pair basic.tests.ModelTest.test_eq @@ -276,25 +256,19 @@ will pair ``test_eq`` with every test label. With both ``--bisect`` and ``--pair``, if you already suspect which cases might be responsible for the failure, you may limit tests to be cross-analyzed by :ref:`specifying further test labels ` after -the first one: - -.. code-block:: bash +the first one:: $ ./runtests.py --pair basic.tests.ModelTest.test_eq queries transactions You can also try running any set of tests in reverse using the ``--reverse`` option in order to verify that executing tests in a different order does not -cause any trouble: - -.. code-block:: bash +cause any trouble:: $ ./runtests.py basic --reverse If you wish to examine the SQL being run in failing tests, you can turn on :ref:`SQL logging ` using the ``--debug-sql`` option. If you -combine this with ``--verbosity=2``, all SQL queries will be output. - -.. code-block:: bash +combine this with ``--verbosity=2``, all SQL queries will be output:: $ ./runtests.py basic --debug-sql diff --git a/docs/internals/howto-release-django.txt b/docs/internals/howto-release-django.txt index 624489503e..885b8b34d5 100644 --- a/docs/internals/howto-release-django.txt +++ b/docs/internals/howto-release-django.txt @@ -2,6 +2,8 @@ How is Django Formed? ===================== +.. highlight:: console + This document explains how to release Django. **Please, keep these instructions up-to-date if you make changes!** The point @@ -54,9 +56,7 @@ You'll need a few things before getting started: ``you@example.com`` is the email address associated with the key you want to use. -* An install of some required Python packages: - - .. code-block:: bash +* An install of some required Python packages:: $ pip install wheel twine @@ -117,7 +117,7 @@ any time leading up to the actual release: rather than the releaser, but here are the steps. Provided you have an account on Transifex:: - python scripts/manage_translations.py fetch + $ python scripts/manage_translations.py fetch and then commit the changed/added files (both .po and .mo). Sometimes there are validation errors which need to be debugged, so avoid doing this task @@ -148,16 +148,16 @@ OK, this is the fun part, where we actually push out a release! #. A release always begins from a release branch, so you should make sure you're on a stable branch and up-to-date. For example:: - git checkout stable/1.5.x - git pull + $ git checkout stable/1.5.x + $ git pull #. If this is a security release, merge the appropriate patches from ``django-private``. Rebase these patches as necessary to make each one a simple commit on the release branch rather than a merge commit. To ensure this, merge them with the ``--ff-only`` flag; for example:: - git checkout stable/1.5.x - git merge --ff-only security/1.5.x + $ git checkout stable/1.5.x + $ git merge --ff-only security/1.5.x (This assumes ``security/1.5.x`` is a branch in the ``django-private`` repo containing the necessary security patches for the next release in the 1.5 @@ -193,7 +193,7 @@ OK, this is the fun part, where we actually push out a release! #. Tag the release using ``git tag``. For example:: - git tag --sign --message="Tag 1.5.1" 1.5.1 + $ git tag --sign --message="Tag 1.5.1" 1.5.1 You can check your work by running ``git tag --verify ``. @@ -205,9 +205,7 @@ OK, this is the fun part, where we actually push out a release! create the release packages in a ``dist/`` directory. Note that we don't publish wheel files for 1.4. -#. Generate the hashes of the release packages: - - .. code-block:: bash +#. Generate the hashes of the release packages:: $ cd dist $ md5sum * @@ -217,7 +215,9 @@ OK, this is the fun part, where we actually push out a release! #. Create a "checksums" file, ``Django-<>.checksum.txt`` containing the hashes and release information. Start with this template and insert the correct version, date, GPG key ID (from - ``gpg --list-keys --keyid-format LONG``), release URL, and checksums:: + ``gpg --list-keys --keyid-format LONG``), release URL, and checksums: + + .. code-block:: text This file contains MD5, SHA1, and SHA256 checksums for the source-code tarball of Django <>, released <>. @@ -276,22 +276,16 @@ Making the release(s) available to the public Now you're ready to actually put the release out there. To do this: #. Upload the release package(s) to the djangoproject server, replacing - A.B. with the appropriate version number, e.g. 1.5 for a 1.5.x release: - - .. code-block:: bash + A.B. with the appropriate version number, e.g. 1.5 for a 1.5.x release:: $ scp Django-* djangoproject.com:/home/www/www/media/releases/A.B -#. Upload the checksum file(s): - - .. code-block:: bash +#. Upload the checksum file(s):: $ scp Django-A.B.C.checksum.txt.asc djangoproject.com:/home/www/www/media/pgp/Django-A.B.C.checksum.txt #. Test that the release packages install correctly using ``easy_install`` - and ``pip``. Here's one method (which requires `virtualenvwrapper`__): - - .. code-block:: bash + and ``pip``. Here's one method (which requires `virtualenvwrapper`__):: $ RELEASE_VERSION='1.7.2' $ MAJOR_VERSION=`echo $RELEASE_VERSION| cut -c 1-3` @@ -318,9 +312,7 @@ Now you're ready to actually put the release out there. To do this: correct (proper version numbers, no stray ``.pyc`` or other undesirable files). -#. Upload the release packages to PyPI: - - .. code-block:: bash +#. Upload the release packages to PyPI:: $ twine upload -s dist/* @@ -334,7 +326,7 @@ Now you're ready to actually put the release out there. To do this: #. Make the blog post announcing the release live. #. For a new version release (e.g. 1.5, 1.6), update the default stable version - of the docs by flipping the ``is_default`` flag to ``True`` on the + of the docs by flipping the ``is_default`` flag to `deployment/wsgi/uwsgi.html`True`` on the appropriate ``DocumentRelease`` object in the ``docs.djangoproject.com`` database (this will automatically flip it to ``False`` for all others); you can do this using the site's admin. diff --git a/docs/intro/overview.txt b/docs/intro/overview.txt index f8aea47890..e9f574a4f5 100644 --- a/docs/intro/overview.txt +++ b/docs/intro/overview.txt @@ -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 diff --git a/docs/intro/tutorial01.txt b/docs/intro/tutorial01.txt index bfce99de0b..e03febcced 100644 --- a/docs/intro/tutorial01.txt +++ b/docs/intro/tutorial01.txt @@ -15,7 +15,7 @@ It'll consist of two parts: We'll assume you have :doc:`Django installed ` 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: @@ -577,7 +577,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 diff --git a/docs/intro/tutorial02.txt b/docs/intro/tutorial02.txt index e45753b40f..3dacc62369 100644 --- a/docs/intro/tutorial02.txt +++ b/docs/intro/tutorial02.txt @@ -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 diff --git a/docs/intro/whatsnext.txt b/docs/intro/whatsnext.txt index 6da2aa830b..dd89da7ebe 100644 --- a/docs/intro/whatsnext.txt +++ b/docs/intro/whatsnext.txt @@ -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 diff --git a/docs/ref/contrib/gis/install/geolibs.txt b/docs/ref/contrib/gis/install/geolibs.txt index 4cc2730e51..9ebea30283 100644 --- a/docs/ref/contrib/gis/install/geolibs.txt +++ b/docs/ref/contrib/gis/install/geolibs.txt @@ -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 diff --git a/docs/ref/contrib/gis/tutorial.txt b/docs/ref/contrib/gis/tutorial.txt index 05f3c8360b..c93e55ec69 100644 --- a/docs/ref/contrib/gis/tutorial.txt +++ b/docs/ref/contrib/gis/tutorial.txt @@ -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 `: -.. code-block:: bash +.. code-block:: console $ createdb -T template_postgis geodjango @@ -66,7 +66,7 @@ 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] [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 diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt index fedec7aefa..4d969889d5 100644 --- a/docs/ref/django-admin.txt +++ b/docs/ref/django-admin.txt @@ -38,7 +38,7 @@ be consistent, but any example can use ``manage.py`` just as well. Usage ===== -.. code-block:: bash +.. code-block:: console $ django-admin [options] $ manage.py [options] diff --git a/docs/releases/1.0-porting-guide.txt b/docs/releases/1.0-porting-guide.txt index a8b4ccaa26..d38c14703c 100644 --- a/docs/releases/1.0-porting-guide.txt +++ b/docs/releases/1.0-porting-guide.txt @@ -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 ```` in the code below with each app's name: -.. code-block:: bash +.. code-block:: console $ ./manage.py dumpdata --format=xml > data-dump.xml $ ./manage.py reset @@ -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 diff --git a/docs/topics/i18n/timezones.txt b/docs/topics/i18n/timezones.txt index d6e07d0229..0b0e0d136c 100644 --- a/docs/topics/i18n/timezones.txt +++ b/docs/topics/i18n/timezones.txt @@ -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 diff --git a/docs/topics/install.txt b/docs/topics/install.txt index fb46caf189..ab26e8e003 100644 --- a/docs/topics/install.txt +++ b/docs/topics/install.txt @@ -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.) diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt index a8637bf381..f3b78d3b31 100644 --- a/docs/topics/testing/tools.txt +++ b/docs/topics/testing/tools.txt @@ -760,9 +760,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 @@ -778,9 +778,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. @@ -791,9 +791,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:: @@ -824,9 +824,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