Unix/Linux Go Back    


CentOS 7.0 - man page for epydocgui (centos section 1)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)


EPYDOCGUI(1)									     EPYDOCGUI(1)

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  subdi-
       rectories  are  created for the public and private documentation.  Within each subdirecto-
       ries, 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 docu-
	      mentation 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.  class 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  vari-
		  able	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 encoun-
       ters an error, it issues a warning message that describes the error, and attempts to  con-
       tinue 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  gen-
       erate 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  sec-
		  tion that contains it.

	   Improper paragraph indentation.
		  The paragraphs within a block are not left-aligned.  This error is often gener-
		  ated 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 for-
		  mer, 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 sec-
		  tions; "-" 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 for-
		  matted.  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 warn-
       ings:

	   @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 parame-
		  ter name.

	   @type for unknown variable var.
		  A  @type field was used to specify the type for a variable, but no other infor-
		  mation 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 parame-
		  ters 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  mecha-
		  nism, 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  docu-
		  mentation  of another object that is assigned the same unique identifier.  How-
		  ever, 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 documen-
		  tation 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  candi-
		  date 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 candi-
		  date 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  candi-
		  date 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.   Other-
		  wise,  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.

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

SEE ALSO
       epydoc(1)

       The epydoc webpage
	      <http://epydoc.sourceforge.net>

       The epytext markup language manual
	      <http://epydoc.sourceforge.net/epytext.html>

										     EPYDOCGUI(1)
Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums


All times are GMT -4. The time now is 09:24 AM.