Tasks and utility functions and classes for working with project documentation.
Looks up SectionedFiles relative to the basedir.
When called with a 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.
You can pass in include_markers which is a dictionary that maps file extensions to the single line comment character for that file type. If there is an include marker available, then output like:
# section ‘sectionname’ from ‘file.py’
There are some default include markers. If you don’t pass in anything, no include markers will be displayed. If you pass in an empty dictionary, the default ones will be displayed.
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:
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:
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:
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.
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]]]
Dictionary mapping file extensions to the single line comment marker for that file. There are some defaults. For example, ‘py’ maps to ‘# ‘. If there is a known include marker for a given file, then a comment will be displayed along the lines of:
# section ‘SECTIONNAME’ in file ‘foo.py’
If this option is not set, these lines will not be displayed at all. If this option is set to an empty dictionary, the default include markers will be displayed. You can also pass in your own extension -> include marker settings.
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.