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>
