Ubuntu Manpage: epydocgui - graphical interface to epydoc

Provided by: python-epydoc_3.0.1+dfsg-12_all

NAME

       epydocgui - graphical interface to epydoc

SYNOPSIS

       epydocgui [project.prj | modules...]

       epydoc -h

       epydoc -V

DESCRIPTION

       epydocgui is a graphical interface to epydoc, which generates API documentation for Python
       modules and packages, based on their docstrings.  A  lightweight  markup  language  called
       epytext  can  be  used to format docstrings, and to add information about specific fields,
       such as parameters and instance variables.

       The API documentation produced by  epydocgui  consists  of  a  set  of  HTML  files.   Two
       subdirectories  are  created  for  the  public  and  private  documentation.   Within each
       subdirectories, every class and module is documented in its own file.  An  index  file,  a
       trees  file,  and  a  help file are also created.  If you select the frames option, then a
       frames-based table of contents is also produced.

OPTIONS

       project.prj
              The name of a project file that was saved with epydocgui.  Project files  record  a
              list  of  related  modules,  and  the  options  that should be used to generate the
              documentation for those modules.

       modules...
              The list of the modules that should be documented.  Modules can be specified  using
              module names (such as os.path), filenames (such as epydoc/epytext.py), or directory
              names (such as epydoc/).  Directory names specify packages,  and  are  expanded  to
              include all sub-modules and sub-packages.

       -h, --help, --usage, -?
              Display a usage message.

       -V, --version
              Print the version of Epydoc.

HTML FILES

The API documentation produced by epydoc consists of the following files:

index.html
The standard entry point for the documentation. Normally, index.html is a
frame index file, which defines three frames: two frames on the left side of
the browser contain a table of contents, and the main frame on the right side
of the window contains documentation pages. But if the --no-frames option is
used, then index.html will redirect the user to the project's top page.

m-module.html
The API documentation for a module. module is the complete dotted name of the
module, such as sys or epydoc.epytext.

c-class.html
The API documentation for a class, exception, or type. c is the complete
dotted name of the class, such as epydoc.epytext.Token or array.ArrayType.

trees.html
The module and class hierarchies.

indices.html
The term and identifier indices.

help.html
The help page for the project. This page explains how to use and navigate the
webpage produced by epydoc.

toc.html
The top-level table of contents page. This page is displayed in the upper-left
frame, and provides links to toc-everything.html and the toc-m-module.html
files. toc.html is not generated if the --no-frames option is used.

toc-everything.html
The table of contents for the entire project. This page is displayed in the
lower-left frame, and provides links to every class, type, exception, function,
and variable defined by the project. toc-everything.html is not generated if
the --no-frames option is used.

toc-m-module.html
The table of contents for a module. This page is displayed in the lower-left
frame, and provides links to every class, type, exception, function, and
variable defined by the module. module is the complete dotted name of the
module, such as sys or epydoc.epytext. toc-m-module.html is not generated if
the --no-frames option is used.

epydoc.css
The CSS stylesheet used to display all HTML pages.

By default, epydoc creates two subdirectories in the output directory: public and private.
Each directory contains all of the files specified above. But if the --no-private option
is used, then no subdirectories are created, and the public documentation is written
directly to the output directory. ivided into five categories: import errors; epytext
errors; epytext warnings; field warnings; and inspection errors. Whenver epydoc
encounters an error, it issues a warning message that describes the error, and attempts to
continue generating documentation.

Import errors indicate that epydoc was unable to import a module. Import errors typically
prevent epydoc from generating documentation for the module in question. Epydoc can
generate the following import errors:

Bad module name module
Epydoc attempted to import module, but module is not a valid name for a Python
module.

Could not find a UID for link-target
Epydoc was unable to find the object referred to by an inline link construction
(L{...}). This is usually caused by a typo in the link.

Could not import module
Epydoc attempted to import module, but it failed. This typically occurs when
module raises an exception.

file does not exist
Epydoc attempted to import the module contained in file, but file does not
exist.

Epytext errors are caused by epytext docstrings that contain invalid markup. Whenever an
epytext error is detected, the docstring in question is treated as a plaintext docstring.
Epydoc can generate the following epytext errors:

Bad link target.
The target specified for an inline link contruction (L{...}) is not well-
formed. Link targets must be valid python identifiers.

Bad uri target.
The target specified for an inline uri contruction (U{...}) is not well-formed.
This typically occurs if inline markup is nested inside the URI target.

Fields must be at the top level.
The list of fields (@param, etc.) is contained by some other block structure
(such as a list or a section).

Fields must be the final elements.
The list of fields (@param, etc.) is not at the end of a docstring.

Headings must occur at top level.
The heading is contianed in some other block structure (such as a list).

Improper doctest block indentation.
The doctest block dedents past the indentation of its initial prompt line.

Improper heading indentation.
The heading for a section is not left-aligned with the paragraphs in the
section that contains it.

Improper paragraph indentation.
The paragraphs within a block are not left-aligned. This error is often
generated when plaintext docstrings are parsed using epytext.

Invalid escape.
An unknown escape sequence was used with the inline escape construction
(E{...}).

Lists must be indented.
An unindented line immediately following a paragraph starts with a list bullet.
Epydoc is not sure whether you meant to start a new list item, or meant for a
paragraph to include a word that looks like a bullet. If you intended the
former, then indent the list. If you intended the latter, then change the
word-wrapping of the paragraph, or escape the first character of the word that
looks like a bullet.

Unbalanced '{'.
The docstring contains unbalanced braces. Epytext requires that all braces
must be balanced. To include a single unbalanced brace, use the escape
sequences E{lb} (left brace) and E{rb} (right brace).

Unbalanced '}'.
The docstring contains unbalanced braces. Epytext requires that all braces
must be balanced. To include a single unbalanced brace, use the escape
sequences E{lb} (left brace) and E{rb} (right brace).

Unknown inline markup tag.
An unknown tag was used with the inline markup construction ( x{...} ).

Wrong underline character for heading.
The underline character used for this section heading does not indicate an
appopriate section level. The "=" character should be used to underline
sections; "-" for subsections; and "~" for subsubsections.

Epytext warnings are caused by epytext docstrings that contain questionable or suspicious
markup. Epytext warnings do not prevent the docstring in question from being parsed.
Epydoc can generate the following epytext warnings:

Possible mal-formatted field item.
Epytext detected a line that looks like a field item, but is not correctly
formatted. This typically occurs when the trailing colon (":") is not included
in the field tag.

Possible heading typo.
Epytext detected a pair of lines that looks like a heading, but the number of
underline characters does not match the number of characters in the heading.
The number of characters in these two lines must match exactly for them to be
considered a heading.

Field warnings are caused by epytext docstrings containing invalid fields. The contents
of the invalid field are generally ignored. Epydoc can generate the following field
warnings:

@param for unknown parameter param.
A @param field was used to specify the type for a parameter that is not
included in the function's signature. This is typically caused by a typo in
the parameter name.

tag did not expect an argument.
The field tag tag was used with an argument, but it does not take one.

tag expected an argument.
The field tag tag was used without an argument, but it requires one.

@type for unknown parameter param.
A @type field was used to specify the type for a parameter that is not included
in the function's signature. This is typically caused by a typo in the
parameter name.

@type for unknown variable var.
A @type field was used to specify the type for a variable, but no other
information is known about the variable. This is typically caused by a typo in
the variable name.

Unknown field tag tag.
A docstring contains a field with the unknown tag tag.

Redefinition of field.
Multiple field tags define the value of field in the same docstring, but field
can only take a single value.

Inspection errors are generated if epydoc encounters problems while attempting to inspect
the properties of a documented object. Most of inspection errors do not prevent epydoc
from documenting the object in question. Epydoc can generate the following inspection
errors:

The parameters of inhmethod do not match basemethod.
The parameters of the undocumented method inhmethod do not match the parameters
of the base class method basemethod that it overrides. As a result, inhmethod
does not inherit documentation from basemethod. If the difference in
parameters is intentional, then you can eliminate the warning by adding a
(possibly empty) docstring to inhmethod.

Docmap cannot add a type
Epydoc attempted to document an object with an unknown type. This error is
typically generated by packages and modules that manipulate the import
mechanism, such that importing a module produces some other type of object.

UID conflict detected: uid
Two different objects were assigned the same unique identifier by epydoc. This
can cause epydoc to substitute the documentation of one object with the
documentation of another object that is assigned the same unique identifier.
However, this will usually only cause problems if the two objects with the same
unique identifiers are both modules or classes, in which case the API
documentation page for one object will overwrite the API documentation page for
the other object.

object appears in multiple builtin modules
While attempting to determine which module defines the builtin object object,
epydoc encountered multiple candidates, and was unable to decide which
candidate was correct. In this case, epydoc arbitrarily chooses the first
candidate that it finds.

object appears in multiple .py modules
While attempting to determine which module defines the builtin object object,
epydoc encountered multiple candidates, and was unable to decide which
candidate was correct. In this case, epydoc arbitrarily chooses the first
candidate that it finds.

object appears in multiple .so modules
While attempting to determine which module defines the builtin object object,
epydoc encountered multiple candidates, and was unable to decide which
candidate was correct. In this case, epydoc arbitrarily chooses the first
candidate that it finds.

Could not find a module for object
Epydoc was unable to determine which module defines object. If object is a
function, then this will prevent epydoc from generating any documentation for
object, since it does not know what page to put the documentation on.
Otherwise, this will prevent the documentation for object from including a link
to its containing module.

AUTHOR

       Epydoc was written by Edward Loper.  This man page was originally written by Moshe  Zadka,
       and  is  currently maintained by Edward Loper.  Debian-specific modifications were made by
       Kenneth J. Pronovici.

BUGS

       Report bugs to <edloper@gradient.cis.upenn.edu>.