This lets us better reason about what the parser is doing and use tools
like 'sphinx-contrib.autoprogram' in our own documentation in the
future.
Signed-off-by: Stephen Finucane <stephen@that.guru>
This is pretty self-explanatory, with most changes coming about as a
side-effect of argparse vs. optparse API differences.
Lowercase characters are used in help strings, per argparse conventions.
Some tests are converted because argparse natively supports unicode.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Executable scripts without the '.py' extension are already created and
installed by setuptools, by way of the 'console_scripts' section. These
scripts are unnecessary noise. If people want to test this behavior
locally, use a virtualenv.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Two default-disabled options are enabled:
- show_column_numbers - Shows context notes before errors
- show_error_context - Shows column numbers in error messages
This should make the output of mypy a little easier to parse.
Signed-off-by: Stephen Finucane <stephen@that.guru>
There are still plenty of projects which use custom templates where
DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX.
Currently search does not work in these projects. Make suffix fall
back to .txt since that is the default value of configuration option.
We're going to move the executable's here (or at least those that part
of the core library). The 'sphinx-build' executable was already moved,
so lets do 'sphinx-quickstart' next.
To avoid breaking packages that are using this feature directly, aliases
for the old 'main' method are included. This is based on what Django
does [1] and, like Django, will allow us to safely remove the old
modules in Sphinx 2.0.
[1] https://github.com/django/django/blob/1.11/django/test/runner.py#L688-L695
Signed-off-by: Stephen Finucane <stephen@that.guru>
We have multiple executables in tree and, while 'sphinx-build' is
arguably the most important of these, there's no reason its importance
should warrant inclusion at the package level.
Create a new module, 'sphinx.cmd', and move the code from
'sphinx.__init__' into a 'build' submodule within. This name might be a
bit disingenuous at present, given the availability of 'make-mode' here
too, but that's an artifact of the current executable design and can be
cleaned up later.
To avoid breaking packages that are using this feature directly, aliases
for the old 'main' method are included. This is based on what Django
does [1] and, like Django, will allow us to safely remove the old
modules in Sphinx 2.0.
[1] https://github.com/django/django/blob/1.11/django/test/runner.py#L688-L695
Signed-off-by: Stephen Finucane <stephen@that.guru>
There were a number of package error handlers run as part of the
'sphinx-build' command/executable:
- Unsupported Python version (it should be 2.7 or 3.4+)
- Missing packages (missing docutils, jinja2, and roman, which is part
of docutils, packages)
- Out-of-date packages (docutils)
This code is mostly unchanged since Sphinx was first released. Python,
and in particular Python's packaging options, have come a long way since
then. Today, all of the above checks are provided by setuptools and the
'setup.py' script, meaning we should never actually get to the point of
triggering any of these checks. This is further reinforced by the fact
that none of the other executables carry out these checks: either this
is a bug that no one has reported in ~8 years or, more likely, the
checks are useless and we don't need them anywhere.
In all, we can happily remove these checks, greatly simplify a piece of
code that's otherwise rarely touched, and trust that setuptools is up to
the job it's designed for.
Signed-off-by: Stephen Finucane <stephen@that.guru>
