Merge pull request #197 from masayukig/fix-doc8

Enable doc8

doc/source/MANUAL.rst

@@ -111,11 +111,12 @@ specified test class.
 Test Selection
 --------------
 
-Arguments passed to ``stestr run`` are used to filter test ids that will be run.
-stestr will perform unittest discovery to get a list of all test ids and then
-apply each argument as a regex filter. Tests that match any of the given filters
-will be run. For example, if you called ``stestr run foo bar`` this will only
-run the tests that have a regex match with foo **or** a regex match with bar.
+Arguments passed to ``stestr run`` are used to filter test ids that will be
+run. stestr will perform unittest discovery to get a list of all test ids and
+then apply each argument as a regex filter. Tests that match any of the given
+filters will be run. For example, if you called ``stestr run foo bar`` this
+will only run the tests that have a regex match with foo **or** a regex match
+with bar.
 
 stestr allows you do to do simple test exclusion via passing a rejection/black
 regexp::
@@ -126,8 +127,9 @@ stestr also allow you to combine these arguments::
 
   $ stestr run --black-regex 'slow_tests|bad_tests' ui\.interface
 
-Here first we selected all tests which matches to ``ui\.interface``, then we are
-dropping all test which matches ``slow_tests|bad_tests`` from the final list.
+Here first we selected all tests which matches to ``ui\.interface``, then we
+are dropping all test which matches ``slow_tests|bad_tests`` from the final
+list.
 
 stestr also allows you to specify a blacklist file to define a set of regexes
 to exclude. You can specify a blacklist file with the
@@ -183,9 +185,9 @@ subunit-trace in the module doc: :ref:`subunit_trace`.
 
 However, the test run output is configurable, you can disable this output
 with the ``--no-subunit-trace`` flag which will be completely silent except for
-any failures it encounters. There is also the ``--color`` flag which will enable
-colorization with subunit-trace output. If you prefer to deal with the raw
-subunit yourself and run your own output rendering or filtering you can use
+any failures it encounters. There is also the ``--color`` flag which will
+enable colorization with subunit-trace output. If you prefer to deal with the
+raw subunit yourself and run your own output rendering or filtering you can use
 the ``--subunit`` flag to output the result stream as raw subunit v2.
 
 There is also an ``--abbreviate`` flag available, when this is used a single
@@ -207,10 +209,10 @@ of tests with a different concurrency. In these cases you can use the
 append the subunit stream from the test run into the most recent entry in the
 repository.
 
-Alternatively, you can manually load the test results from a subunit stream into
-an existing test result in the repository using the ``--id``/``-i`` flag on
-the ``stestr load`` command. This will append the results from the input subunit
-stream to the specified id.
+Alternatively, you can manually load the test results from a subunit stream
+into an existing test result in the repository using the ``--id``/``-i`` flag
+on the ``stestr load`` command. This will append the results from the input
+subunit stream to the specified id.
 
 
 Running previously failed tests
@@ -288,9 +290,9 @@ To see a list of tests found by stestr you can use the ``stestr list`` command.
 This will list all tests found by discovery.
 
 You can also use this to see what tests will be run by a given stestr run
-command. For instance, the tests that ``stestr run myfilter`` will run are shown
-by ``stestr list myfilter``. As with the run command, arguments to list are used
-to regex filter the tests.
+command. For instance, the tests that ``stestr run myfilter`` will run are
+shown by ``stestr list myfilter``. As with the run command, arguments to list
+are used to regex filter the tests.
 
 Parallel testing
 ----------------
@@ -484,8 +486,8 @@ Forcing isolation
 -----------------
 
 Sometimes it is useful to force a separate test runner instance for each test
-executed. The ``--isolated`` flag will cause stestr to execute a separate runner
-per test::
+executed. The ``--isolated`` flag will cause stestr to execute a separate
+runner per test::
 
   $ stestr run --isolated
 
@@ -525,8 +527,8 @@ contains the following files:
 * format: This file identifies the precise layout of the repository, in case
   future changes are needed.
 
-* next-stream: This file contains the serial number to be used when adding another
-  stream to the repository.
+* next-stream: This file contains the serial number to be used when adding
+  another stream to the repository.
 
 * failing: This file is a stream containing just the known failing tests. It
   is updated whenever a new stream is added to the repository, so that it only

doc/source/api.rst

@@ -2,10 +2,10 @@
 
 Internal API Reference
 ======================
-This document serves as a reference for the python API used in stestr. It should
-serve as a guide for both internal and external use of stestr components via
-python. The majority of the contents here are built from internal docstrings
-in the actual code.
+This document serves as a reference for the python API used in stestr. It
+should serve as a guide for both internal and external use of stestr components
+via python. The majority of the contents here are built from internal
+docstrings in the actual code.
 
 Repository
 ----------
@@ -54,8 +54,8 @@ However, to make the commands externally consumable each module also contains
 another public function which performs the real work for the command. Each one
 of these functions has a defined stable Python API signature with args and
 kwargs so that people can easily call the functions from other python programs.
-This function is what can be expected to be used outside of stestr as the stable
-interface.
+This function is what can be expected to be used outside of stestr as the
+stable interface.
 All the stable functions can be imported the command module directly::
 
   from stestr import command

doc/source/api/test_processor.rst

@@ -5,9 +5,9 @@ Test Processor Module
 
 This module contains the definition of the ``TestProcessorFixture`` fixture
 class. This fixture is used for handling the actual spawning of worker
-processes for running tests, or listing tests. It is constructed as a `fixture`_
-to handle the lifecycle of the test id list files which are used to pass test
-ids to the workers processes running the tests.
+processes for running tests, or listing tests. It is constructed as a
+`fixture`_ to handle the lifecycle of the test id list files which are used to
+pass test ids to the workers processes running the tests.
 
 .. _fixture: https://pypi.python.org/pypi/fixtures
 

doc/source/internal_arch.rst

@@ -45,8 +45,8 @@ get_parser(prog_name)
 '''''''''''''''''''''
 
 This function is used to define subcommand arguments. It has a single argparse
-parser object passed into it. The intent of this function is to have any command
-specific arguments defined on the provided parser object by calling
+parser object passed into it. The intent of this function is to have any
+command specific arguments defined on the provided parser object by calling
 `parser.add_argument()`_ for each argument.
 
 .. _parser.add_argument(): https://docs.python.org/3/library/argparse.html#the-add-argument-method
@@ -83,8 +83,9 @@ Once there is complete list of tests that will be run the list gets passed
 to the scheduler/partitioner. The scheduler takes the list of tests and splits
 it into N groups where N is the concurrency that stestr will use to run tests.
 If there is any timing data available in the repository from previous runs this
-is used by the scheduler to try balancing the test load between the workers. For
-the full details on how the partitioning is performed see: :ref:`api_scheduler`.
+is used by the scheduler to try balancing the test load between the workers.
+For the full details on how the partitioning is performed see:
+:ref:`api_scheduler`.
 
 With the tests split into multiple groups for each worker process we're
 ready to start executing the tests. Each group of tests is used to launch a

test-requirements.txt

@@ -8,3 +8,4 @@ mock>=2.0 # BSD
 subunit2sql>=1.8.0
 coverage>=4.0 # Apache-2.0
 ddt>=1.0.1 # MIT
+doc8>=0.8.0 # Apache-2.0

tox.ini

@@ -32,7 +32,9 @@ commands =
     coverage html -d cover
 
 [testenv:docs]
-commands = python setup.py build_sphinx
+commands =
+  doc8 -e .rst doc/source CONTRIBUTING.rst README.rst
+  python setup.py build_sphinx
 
 [testenv:releasenotes]
 commands = sphinx-build -a -E -W -d releasenotes/build/doctrees -b html releasenotes/source releasenotes/build/html