Tasks and utility functions and classes for working with project documentation.
Looks up SectionedFiles relative to the basedir.
When called witha filename and an optional section, the Includer will:
If a cog object is provided at initialization, the text will be sent to the CogGenerator (cog.gen) rather than returned as a string.
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.
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.
file glob to look for under basedir. By default, *.rst
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:
[[[cog include('filename_under_includedir.py', 'mysection')]]] [[[end]]]
Build HTML documentation using Sphinx. This uses the following options in a “sphinx” section of the options.
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.