Add interfaces to docs

3 files changed, 30 insertions, 18 deletions

diff --git a/docs/userguide/extension.rst b/docs/userguide/extension.rst
index 0008b6c2..58c8ec19 100644
--- a/docs/userguide/extension.rst
+++ b/docs/userguide/extension.rst
@@ -56,8 +56,8 @@ a ``foo`` command, you might add something like this to your project:
     distutils.commands =
          foo = mypackage.some_module:foo
 
-(Assuming, of course, that the ``foo`` class in ``mypackage.some_module`` is
-a ``setuptools.Command`` subclass.)
+Assuming, of course, that the ``foo`` class in ``mypackage.some_module`` is
+a ``setuptools.Command`` subclass (documented bellow).
 
 Once a project containing such entry points has been activated on ``sys.path``,
 (e.g. by running ``pip install``) the command(s) will be available to any
@@ -72,9 +72,21 @@ Custom commands should try to replicate the same overall behavior as the
 original classes, and when possible, even inherit from them.
 
 You should also consider handling exceptions such as ``CompileError``,
-``LinkError``, ``LibError``, among others.  These exceptions are available in
+``LinkError``, ``LibError``, among others. These exceptions are available in
 the ``setuptools.errors`` module.
 
+.. autoclass:: setuptools.Command
+   :members:
+
+
+Supporting sdists and editable installs in ``build`` sub-commands
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+``build`` sub-commands (like ``build_py`` and ``build_ext``)
+are encouraged to implement the following protocol:
+
+.. autoclass:: setuptools.command.build.SubCommand
+
 
 Adding Arguments
 ----------------
diff --git a/setuptools/__init__.py b/setuptools/__init__.py
index ae53570c..6c24cc2b 100644
--- a/setuptools/__init__.py
+++ b/setuptools/__init__.py
@@ -119,7 +119,7 @@ class Command(_Command):
         Most of the time, each option/attribute/cache should only be set if it does not
         have any value yet (e.g. ``if self.attr is None: self.attr = val``).
 
-    .. method: run(self)
+    .. method:: run(self)
 
         Execute the actions intended by the command.
         (Side effects **SHOULD** only take place when ``run`` is executed,
diff --git a/setuptools/command/build.py b/setuptools/command/build.py
index c35dc3fc..1396afd5 100644
--- a/setuptools/command/build.py
+++ b/setuptools/command/build.py
@@ -44,20 +44,20 @@ class SubCommand(Protocol):
     1. ``setuptools`` will set the ``editable_mode`` flag will be set to ``True``
     2. ``setuptools`` will execute the ``run()`` command.
 
-         .. important::
-            Subcommands **SHOULD** take advantage of ``editable_mode=True`` to adequate
-            its behaviour or perform optimisations.
-
-            For example, if a subcommand don't need to generate any extra file and
-            everything it does is to copy a source file into the build directory,
-            ``run()`` **SHOULD** simply "early return".
-
-            Similarly, if the subcommand creates files that would be placed alongside
-            Python files in the final distribution, during an editable install
-            the command **SHOULD** generate these files "in place" (i.e. write them to
-            the original source directory, instead of using the build directory).
-            Note that ``get_output_mapping()`` should reflect that and include mappings
-            for "in place" builds accordingly.
+       .. important::
+          Subcommands **SHOULD** take advantage of ``editable_mode=True`` to adequate
+          its behaviour or perform optimisations.
+
+          For example, if a subcommand don't need to generate any extra file and
+          everything it does is to copy a source file into the build directory,
+          ``run()`` **SHOULD** simply "early return".
+
+          Similarly, if the subcommand creates files that would be placed alongside
+          Python files in the final distribution, during an editable install
+          the command **SHOULD** generate these files "in place" (i.e. write them to
+          the original source directory, instead of using the build directory).
+          Note that ``get_output_mapping()`` should reflect that and include mappings
+          for "in place" builds accordingly.
 
     3. ``setuptools`` use any knowledge it can derive from the return values of
        ``get_outputs()`` and ``get_output_mapping()`` to create an editable wheel.