Minimal Sphinx setup for autodocumenting Python modules

Published on April 14, 2010 in documentation and Python. 12 Comments

Here’s how to get a nice automatic documentation of your Python code using Sphinx. Sphinx can automagically slurp in all your docstrings, format them nicely, and render them as HTML or PDF output. Your docstrings end up looking so nice that sometimes it makes you want to write more of them! (which of course would result in better-documented code).

Install Sphinx

First you’ll need to get Sphinx. In Ubuntu,

$ sudo easy_install -U sphinx

Configure Sphinx for your module

Then change to your module’s root directory. I like to create a doc subdirectory, since Sphinx does clutter things up a little:

$ cd examplemodule

$ mkdir doc

$ cd doc

When you’re in the directory you want to have your docs in, run

$ sphinx-quickstart

Sphinx will walk you through the setup. Defaults are fine for everything, but make sure you choose y on the “autodoc” question. I’ve highlighted this below. Here’s the complete output of the sphinx-quickstart along with my answers.

Please enter values for the following settings (just press Enter to

accept a default value, if one is given in brackets).

Enter the root path for documentation.

> Root path for the documentation [.]:

You have two options for placing the build directory for Sphinx output.

Either, you use a directory "_build" within the root path, or you separate

"source" and "build" directories within the root path.

> Separate source and build directories (y/N) [n]:

Inside the root directory, two more directories will be created; "_templates"

for custom HTML templates and "_static" for custom stylesheets and other static

files. You can enter another prefix (such as ".") to replace the underscore.

> Name prefix for templates and static dir [_]:

The project name will occur in several places in the built documentation.

> Project name: examplemodule

> Author name(s): Code Monkey

Sphinx has the notion of a "version" and a "release" for the

software. Each version can have multiple releases. For example, for

Python the version is something like 2.5 or 3.0, while the release is

something like 2.5.1 or 3.0a1.  If you don't need this dual structure,

just set both to the same value.

> Project version: 0.1

> Project release [0.1]:

The file name suffix for source files. Commonly, this is either ".txt"

or ".rst".  Only files with this suffix are considered documents.

> Source file suffix [.rst]:

One document is special in that it is considered the top node of the

"contents tree", that is, it is the root of the hierarchical structure

of the documents. Normally, this is "index", but if your "index"

document is a custom template, you can also set this to another filename.

> Name of your master document (without suffix) [index]:

Please indicate if you want to use one of the following Sphinx extensions:

> autodoc: automatically insert docstrings from modules (y/N) [n]: y

> doctest: automatically test code snippets in doctest blocks (y/N) [n]:

> intersphinx: link between Sphinx documentation of different projects (y/N) [n]:

> todo: write "todo" entries that can be shown or hidden on build (y/N) [n]:

> coverage: checks for documentation coverage (y/N) [n]:

> pngmath: include math, rendered as PNG images (y/N) [n]:

> jsmath: include math, rendered in the browser by JSMath (y/N) [n]:

> ifconfig: conditional inclusion of content based on config values (y/N) [n]:

A Makefile and a Windows command file can be generated for you so that you

only have to run e.g. `make html' instead of invoking sphinx-build


> Create Makefile? (Y/n) [y]:

> Create Windows command file? (Y/n) [y]: n

Finished: An initial directory structure has been created.

You should now populate your master file ./index.rst and create other documentation

source files. Use the Makefile to build the docs, like so:

make builder

where "builder" is one of the supported builders, e.g. html, latex or linkcheck.

Edit index.rst

Now you’re ready to edit the index.rst page. All you need for this minimal setup is to add an automodule directive for the module (to tell Sphinx what the current module is that’s being documented) and then the autoclass directive for each class you want to have documented. The :members: command tells Sphinx to document any class members that have a docstring.

.. automodule:: examplemodule

.. autoclass:: myClass


.. autoclass:: anotherClass


So here’s what a complete index.rst might look like for a module with two classes that I want to document:

.. pybedtools documentation master file, created by

sphinx-quickstart on Tue Apr 13 18:15:46 2010.

You can adapt this file completely to your liking, but it

should at least contain the root `toctree` directive.

Welcome to examplemodule's documentation!



.. toctree::

:maxdepth: 2

.. automodule:: examplemodule

.. autoclass:: myClass


.. autoclass:: anotherClass


Indices and tables


* :ref:`genindex`

* :ref:`modindex`

* :ref:`search`

The Sphinx documentation site has more info on the documentation for the autodoc extension, for example, specifying only a couple of members or documenting functions.

Make sure your module is importable

Sphinx actually imports your module in order to get all the docstrings. So you’ll need to make sure that your module is importable. Easiest way is to add it to your PYTHONPATH:

$ export PYTHONPATH=$PYTHONPATH:/path/to/examplemodule

Create the docs

Now, from within the documentation directory, create HTML docs with

$ make html

and open the file _build/html/index.html to see your new documentation.

If you want to go the fancy PDF route, you’ll need to make sure you have LaTeX on your machine. An easy way to get it on Ubuntu is to install Kile, which will automatically install all of Kile’s LaTeX dependencies

$ sudo apt-get install kile

Once you have LaTeX, make the PDF docs with

$ make latex

$ cd _build/latex

$ make all-pdf

and then open the file _build/latex/examplemodule.pdf to see the results.


Here’s a screenshot of the HTML version:
sphinx html example output

And here’s the PDF output:

Again, the autodoc documentation has lots more info for further customizing this