Documentation Tools

Tasks and utility functions and classes for working with project documentation.

class paver.doctools.Includer(basedir, cog=None)

Looks up SectionedFiles relative to the basedir.

When called witha filename and an optional section, the Includer will:

  1. look up that file relative to the basedir in a cache
  2. load it as a SectionedFile if it’s not in the cache
  3. return the whole file if section is None
  4. return just the section desired if a section is requested

If a cog object is provided at initialization, the text will be sent to the CogGenerator (cog.gen) rather than returned as a string.

class paver.doctools.SectionedFile(filename=None, from_string=None)

Loads a file into memory and keeps track of all of the sections found in the file. Sections are started with a line that looks like this:

[[[section SECTIONNAME]]]

Anything else can appear on the line outside of the brackets (so if you’re in a source code file, you can put the section marker in a comment). The entire lines containing the section markers are not included when you request the text from the file.

An end of section marker looks like this:

[[[endsection]]]

Sections can be nested. If you do nest sections, you will use dotted notation to refer to the inner sections. For example, a “dessert” section within an “order” section would be referred to as “order.dessert”.

The SectionedFile provides dictionary-style access to the sections. If you have a SectionedFile named ‘sf’, sf[sectionname] will give you back a string of that section of the file, including any inner sections. There won’t be any section markers in that string.

You can get the text of the whole file via the all property (for example, sf.all).

Section names must be unique across the file, but inner section names are kept track of by the full dotted name. So you can have a “dessert” section that is contained within two different outer sections.

Ending a section without starting one or ending the file without ending a section will yield BuildFailures.

all
Property to get access to the whole file.
paver.doctools.cog()

Runs the cog code generator against the files matching your specification. By default, cog will run against any .rst files in your Sphinx document root. Full documentation for Cog is here:

http://nedbatchelder.com/code/cog/

In a nutshell, you put blocks in your file that look like this:

[[[cog cog.outl(“Hi there!”) ]]] [[[end]]]

Cog will replace the space between ]]] and [[[end]]] with the generated output. In this case, Hi there!

Here are the options available for the cog task. These are looked up in the ‘cog’ options section by default. The ‘sphinx’ option set is also searched.

basedir
directory to look in for files to cog. If not set, ‘docroot’ is looked up.
pattern

file glob to look for under basedir. By default, *.rst

System Message: WARNING/2 (/Users/admin/projects/paver/docs/source/doctools.rst, line 100); backlink

Inline emphasis start-string without end-string.
includedir

If you have external files to include in your documentation, setting includedir to the root of those files will put a paver.doctools.Includer in your Cog namespace as ‘include’. This lets you easily include files and sections of files. Here’s an example usage:

System Message: ERROR/3 (<docstring of paver.doctools.cog>, line 35)

Unexpected indentation.
[[[cog include('filename_under_includedir.py', 'mysection')]]]
[[[end]]]
beginspec
String used at the beginning of the code generation block. Default: [[[cog
endspec
String used at the end of the code generation block. Default; ]]]
endoutput
String used at the end of the generated output Default: [[[end]]]
paver.doctools.doc_clean()
Clean (delete) the built docs. Specifically, this deletes the build directory under the docroot. See the html task for the options list.
paver.doctools.html()

Build HTML documentation using Sphinx. This uses the following options in a “sphinx” section of the options.

docroot
the root under which Sphinx will be working. Default: docs
builddir
directory under the docroot where the resulting files are put. default: build
sourcedir
directory under the docroot for the source files default: (empty string)
paver.doctools.uncog()

Remove the Cog generated code from files. Often, you will want to do this before committing code under source control, because you don’t generally want generated code in your version control system.

This takes the same options as the cog task. Look there for more information.