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>
The 'sphinx-apidoc' tool is no longer the only kid on the block when it
comes to automatic documentation of Python projects, with the likes of
'sphinx-autoapi' in development [1], and is not really maintained. Given
the fact that the tool is tangential to Sphinx's main goal, there isn't
really anything that warrants its continue existence as a core module.
Signify this by moving the feature to 'ext'. This allows the feature to
continue to exist in the package, but indicates that stability might be
worse than one would expect from the core library.
To avoid breaking packages that are using this feature directly, such as
pbr [3], aliases for the old 'main' method are included. This is based
on what Django does and, like Django, will allow us to safely remove the
old modules in Sphinx 2.0.
[1] https://github.com/rtfd/sphinx-autoapi
[2] https://github.com/sphinx-doc/sphinx/pull/3485#issuecomment-288081223
[3] https://github.com/django/django/blob/1.11/django/test/runner.py#L688-L695
Signed-off-by: Stephen Finucane <stephen@that.guru>
