.. _documenting-matplotlib: ===================== Writing documentation ===================== Getting started =============== General file structure ---------------------- All documentation is built from the :file:`doc/` directory. This directory contains both reStructuredText (ReST_; ``.rst``) files that contain pages in the documentation and configuration files for Sphinx_. The ``.rst`` files are kept in :file:`doc/users`, :file:`doc/devel`, :file:`doc/api` and :file:`doc/faq`. The main entry point is :file:`doc/index.rst`, which pulls in the :file:`index.rst` file for the users guide, developers guide, api reference, and FAQs. The documentation suite is built as a single document in order to make the most effective use of cross referencing. Sphinx_ also creates ``.rst`` files that are staged in :file:`doc/api` from the docstrings of the classes in the Matplotlib library. Except for :file:`doc/api/api_changes/`, these ``.rst`` files are created when the documentation is built. Similarly, the contents of :file:`docs/gallery` and :file:`docs/tutorials` are generated by the `Sphinx Gallery`_ from the sources in :file:`examples` and :file:`tutorials`. These sources consist of python scripts that have ReST_ documentation built into their comments. Don't directly edit the ``.rst`` files in :file:`docs/gallery` and :file:`docs/tutorials` as they are regenerated when the documentation are built. Installing dependencies ----------------------- The documentation for Matplotlib is generated from reStructuredText (ReST_) using the Sphinx_ documentation generation tool. There are several extra requirements that are needed to build the documentation. They are listed in :file:`doc-requirements.txt` and listed below: * Sphinx>=1.3, !=1.5.0, !=1.6.4 * colorspacious * IPython * mock * numpydoc>=0.4 * Pillow * sphinx-gallery>=0.1.12 * graphviz .. note:: * You'll need a minimal working LaTeX distribution for many examples to run. * `Graphviz `_ is not a Python package, and needs to be installed separately. Building the docs ----------------- The documentation sources are found in the :file:`doc/` directory in the trunk. The configuration file for Sphinx is :file:`doc/conf.py`. It controls which directories Sphinx parses, how the docs are built, and how the extensions are used. To build the documentation in html format, cd into :file:`doc/` and run: .. code-block:: sh make html Other useful invocations include .. code-block:: sh # Delete built files. May help if you get errors about missing paths or # broken links. make clean # Build pdf docs. make latexpdf The ``SPHINXOPTS`` variable is set to ``-W`` by default to turn warnings into errors. To unset it, use .. code-block:: sh make SPHINXOPTS= html You can use the ``O`` variable to set additional options: * ``make O=-j4 html`` runs a parallel build with 4 processes. * ``make O=-Dplot_formats=png:100 html`` saves figures in low resolution. * ``make O=-Dplot_gallery=0 html`` skips the gallery build. Multiple options can be combined using e.g. ``make O='-j4 -Dplot_gallery=0' html``. On Windows, options needs to be set as environment variables, e.g. ``set O=-W -j4 & make html``. .. _writing-rest-pages: Writing ReST pages ================== Most documentation is either in the docstring of individual classes and methods, in explicit ``.rst`` files, or in examples and tutorials. All of these use the ReST_ syntax. Users should look at the ReST_ documentation for a full description. But some specific hints and conventions Matplotlib uses are useful for creating documentation. Formatting and style conventions -------------------------------- It is useful to strive for consistency in the Matplotlib documentation. Here are some formatting and style conventions that are used. Section name formatting ~~~~~~~~~~~~~~~~~~~~~~~ For everything but top-level chapters, use ``Upper lower`` for section titles, e.g., ``Possible hangups`` rather than ``Possible Hangups`` Function arguments ~~~~~~~~~~~~~~~~~~ Function arguments and keywords within docstrings should be referred to using the ``*emphasis*`` role. This will keep Matplotlib's documentation consistent with Python's documentation: .. code-block:: rst Here is a description of *argument* Do not use the ```default role```: .. code-block:: rst Do not describe `argument` like this. As per the next section, this syntax will (unsuccessfully) attempt to resolve the argument as a link to a class or method in the library. nor the ````literal```` role: .. code-block:: rst Do not describe ``argument`` like this. .. _internal-section-refs: Referring to other documents and sections ----------------------------------------- Sphinx_ allows internal references_ between documents. Documents can be linked with the `:doc:` directive: .. code-block:: rst See the :doc:`/faq/installing_faq` See the tutorial :doc:`/tutorials/introductory/sample_plots` See the example :doc:`/gallery/lines_bars_and_markers/simple_plot` will render as: See the :doc:`/faq/installing_faq` See the tutorial :doc:`/tutorials/introductory/sample_plots` See the example :doc:`/gallery/lines_bars_and_markers/simple_plot` Sections can also be given reference names. For instance from the :doc:`/faq/installing_faq` link: .. code-block:: rst .. _clean-install: How to completely remove Matplotlib =================================== Occasionally, problems with Matplotlib can be solved with a clean... and refer to it using the standard reference syntax: .. code-block:: rst See :ref:`clean-install` will give the following link: :ref:`clean-install` To maximize internal consistency in section labeling and references, use hyphen separated, descriptive labels for section references. Keep in mind that contents may be reorganized later, so avoid top level names in references like ``user`` or ``devel`` or ``faq`` unless necessary, because for example the FAQ "what is a backend?" could later become part of the users guide, so the label: .. code-block:: rst .. _what-is-a-backend: is better than: .. code-block:: rst .. _faq-backend: In addition, since underscores are widely used by Sphinx itself, use hyphens to separate words. Referring to other code ----------------------- To link to other methods, classes, or modules in Matplotlib you can use back ticks, for example: .. code-block:: python `~matplotlib.collections.LineCollection` returns a link to the documentation of `~matplotlib.collections.LineCollection`. For the full path of the class to be shown, omit the tilde: .. code-block:: python `matplotlib.collections.LineCollection` to get `matplotlib.collections.LineCollection`. It is often not necessary to fully specify the class hierarchy unless there is a namespace collision between two packages: .. code-block:: python `~.LineCollection` links just as well: `~.LineCollection`. Other packages can also be linked via ``intersphinx``: .. code-block:: Python `numpy.mean` will return this link: `numpy.mean`. This works for Python, Numpy, Scipy, and Pandas (full list is in :file:`doc/conf.py`). Sometimes it is tricky to get external Sphinx linking to work; to check that a something exists to link to the following shell command outputs a list of all objects that can be referenced (in this case for Numpy):: python -m sphinx.ext.intersphinx 'https://docs.scipy.org/doc/numpy/objects.inv' .. _rst-figures-and-includes: Including figures and files --------------------------- Image files can directly included in pages with the ``image::`` directive. e.g., :file:`users/navigation_toolbar.rst` displays the toolbar icons with a call to a static image:: .. image:: ../_static/toolbar.png as rendered on the page: :ref:`navigation-toolbar`. Files can be included verbatim. For instance the ``matplotlibrc`` file is important for customizing Matplotlib, and is included verbatim in the tutorial in :doc:`/tutorials/introductory/customizing`:: .. literalinclude:: ../../_static/matplotlibrc This is rendered at the bottom of :doc:`/tutorials/introductory/customizing`. Note that this is in a tutorial; see :ref:`writing-examples-and-tutorials` below. The examples directory is also copied to :file:`doc/gallery` by sphinx-gallery, so plots from the examples directory can be included using .. code-block:: rst .. plot:: gallery/pylab_examples/simple_plot.py Note that the python script that generates the plot is referred to, rather than any plot that is created. Sphinx-gallery will provide the correct reference when the documentation is built. .. _writing-docstrings: Writing docstrings ================== Much of the documentation lives in "docstrings". These are comment blocks in source code that explain how the code works. All new or edited docstrings should conform to the numpydoc guidelines. These split the docstring into a number of sections - see the `numpy documentation howto`_ for more details and a guide to how docstrings should be formatted. Much of the ReST_ syntax discussed above (:ref:writing-rest-pages) can be used for links and references. These docstrings eventually populate the :file:`doc/api` directory and form the reference documentation for the library. Example docstring ----------------- An example docstring looks like: .. code-block:: python def hlines(self, y, xmin, xmax, colors='k', linestyles='solid', label='', **kwargs): """ Plot horizontal lines at each *y* from *xmin* to *xmax*. Parameters ---------- y : scalar or sequence of scalar y-indexes where to plot the lines. xmin, xmax : scalar or 1D array_like Respective beginning and end of each line. If scalars are provided, all lines will have same length. colors : array_like of colors, optional, default: 'k' linestyles : {'solid', 'dashed', 'dashdot', 'dotted'}, optional label : string, optional, default: '' Returns ------- lines : `~matplotlib.collections.LineCollection` Other Parameters ---------------- **kwargs : `~matplotlib.collections.LineCollection` properties. See also -------- vlines : vertical lines axhline: horizontal line across the axes """ See the `~.Axes.hlines` documentation for how this renders. The Sphinx_ website also contains plenty of documentation_ concerning ReST markup and working with Sphinx in general. .. note:: Some parts of the documentation do not yet conform to the current documentation style. If in doubt, follow the rules given here and not what you may see in the source code. Pull requests updating docstrings to the current style are very welcome. Formatting conventions ---------------------- The basic docstring conventions are covered in the `numpy documentation howto`_ and the Sphinx_ documentation. Some Matplotlib-specific formatting conventions to keep in mind: * Matplotlib does not have a convention whether to use single-quotes or double-quotes. There is a mixture of both in the current code. * Long parameter lists should be wrapped using a ``\`` for continuation and starting on the new line without any indent: .. code-block:: python def add_axes(self, *args, **kwargs): """ ... Parameters ---------- projection : {'aitoff', 'hammer', 'lambert', 'mollweide', 'polar', \ 'rectilinear'}, optional The projection type of the axes. ... """ Alternatively, you can describe the valid parameter values in a dedicated section of the docstring. * Generally, do not add markup to types for ``Parameters`` and ``Returns``. This is usually not needed because Sphinx will link them automatically and would unnecessarily clutter the docstring. However, it does seem to fail in some situations. If you encounter such a case, you are allowed to add markup: .. code-block:: rst Returns ------- lines : `~matplotlib.collections.LineCollection` * rcParams can be referenced with the custom ``:rc:`` role: :literal:`:rc:\`foo\`` yields ``rcParams["foo"]``. Deprecated formatting conventions --------------------------------- * Formerly, we have used square brackets for explicit parameter lists ``['solid' | 'dashed' | 'dotted']``. With numpydoc we have switched to their standard using curly braces ``{'solid', 'dashed', 'dotted'}``. Linking to other code --------------------- To link to other methods, classes, or modules in Matplotlib you can encase the name to refer to in back ticks, for example: .. code-block:: python `~matplotlib.collections.LineCollection` It is also possible to add links to code in Python, Numpy, Scipy, or Pandas. Sometimes it is tricky to get external Sphinx linking to work; to check that a something exists to link to the following shell command outputs a list of all objects that can be referenced (in this case for Numpy):: python -m sphinx.ext.intersphinx 'https://docs.scipy.org/doc/numpy/objects.inv' Function arguments ------------------ Function arguments and keywords within docstrings should be referred to using the ``*emphasis*`` role. This will keep Matplotlib's documentation consistent with Python's documentation: .. code-block:: rst Here is a description of *argument* Do not use the ```default role```: .. code-block:: rst Do not describe `argument` like this. nor the ````literal```` role: .. code-block:: rst Do not describe ``argument`` like this. Setters and getters ------------------- Artist properties are implemented using setter and getter methods (because Matplotlib predates the introductions of the `property` decorator in Python). By convention, these setters and getters are named ``set_PROPERTYNAME`` and ``get_PROPERTYNAME``; the list of properties thusly defined on an artist and their values can be listed by the `~.pyplot.setp` and `~.pyplot.getp` functions. Property setter methods should indicate the values they accept using a (legacy) special block in the docstring, starting with ``ACCEPTS``, as follows: .. code-block:: python # in lines.py def set_linestyle(self, linestyle): """ Set the linestyle of the line ACCEPTS: [ '-' | '--' | '-.' | ':' | 'steps' | 'None' | ' ' | '' ] """ The ACCEPTS block is used to render a table of all properties and their acceptable values in the docs; it can also be displayed using, e.g., ``plt.setp(Line2D)`` (all properties) or ``plt.setp(Line2D, 'linestyle')`` (just one property). There are cases in which the ACCEPTS string is not useful in the generated Sphinx documentation, e.g. if the valid parameters are already defined in the numpydoc parameter list. You can hide the ACCEPTS string from Sphinx by making it a ReST comment (i.e. use ``.. ACCEPTS:``): .. code-block:: python def set_linestyle(self, linestyle): """ An ACCEPTS string invisible to Sphinx. .. ACCEPTS: [ '-' | '--' | '-.' | ':' | 'steps' | 'None' | ' ' | '' ] """ Keyword arguments ----------------- .. note:: The information in this section is being actively discussed by the development team, so use the docstring interpolation only if necessary. This section has been left in place for now because this interpolation is part of the existing documentation. Since Matplotlib uses a lot of pass-through ``kwargs``, e.g., in every function that creates a line (`~.pyplot.plot`, `~.pyplot.semilogx`, `~.pyplot.semilogy`, etc...), it can be difficult for the new user to know which ``kwargs`` are supported. Matplotlib uses a docstring interpolation scheme to support documentation of every function that takes a ``**kwargs``. The requirements are: 1. single point of configuration so changes to the properties don't require multiple docstring edits. 2. as automated as possible so that as properties change, the docs are updated automatically. The function `matplotlib.artist.kwdoc` and the decorator `matplotlib.docstring.dedent_interpd` facilitate this. They combine Python string interpolation in the docstring with the Matplotlib artist introspection facility that underlies ``setp`` and ``getp``. The ``kwdoc`` function gives the list of properties as a docstring. In order to use this in another docstring, first update the ``matplotlib.docstring.interpd`` object, as seen in this example from `matplotlib.lines`: .. code-block:: python # in lines.py docstring.interpd.update(Line2D=artist.kwdoc(Line2D)) Then in any function accepting `~.Line2D` pass-through ``kwargs``, e.g., `matplotlib.axes.Axes.plot`: .. code-block:: python # in axes.py @docstring.dedent_interpd def plot(self, *args, **kwargs): """ Some stuff omitted The kwargs are Line2D properties: %(Line2D)s kwargs scalex and scaley, if defined, are passed on to autoscale_view to determine whether the x and y axes are autoscaled; default True. See Axes.autoscale_view for more information """ Note there is a problem for `~matplotlib.artist.Artist` ``__init__`` methods, e.g., `matplotlib.patches.Patch.__init__`, which supports ``Patch`` ``kwargs``, since the artist inspector cannot work until the class is fully defined and we can't modify the ``Patch.__init__.__doc__`` docstring outside the class definition. There are some some manual hacks in this case, violating the "single entry point" requirement above -- see the ``docstring.interpd.update`` calls in `matplotlib.patches`. .. _docstring-adding-figures: Adding figures -------------- As above (see :ref:`rst-figures-and-includes`), figures in the examples gallery can be referenced with a `:plot:` directive pointing to the python script that created the figure. For instance the `~.Axes.legend` docstring references the file :file:`examples/api/legend.py`: .. code-block:: python """ ... Examples -------- .. plot:: gallery/api/legend.py """ Note that ``examples/api/legend.py`` has been mapped to ``gallery/api/legend.py``, a redirection that may be fixed in future re-organization of the docs. Plots can also be directly placed inside docstrings. Details are in :doc:`/devel/plot_directive`. A short example is: .. code-block:: python """ ... Examples -------- .. plot:: import matplotlib.image as mpimg img = mpimg.imread('_static/stinkbug.png') imgplot = plt.imshow(img) """ An advantage of this style over referencing an example script is that the code will also appear in interactive docstrings. .. _writing-examples-and-tutorials: Writing examples and tutorials ============================== Examples and tutorials are python scripts that are run by `Sphinx Gallery`_ to create a gallery of images in the :file:`/doc/gallery` and :file:`/doc/tutorials` directories respectively. To exclude an example from having an plot generated insert "sgskip" somewhere in the filename. The format of these files is relatively straightforward. Properly formatted comment blocks are treated as ReST_ text, the code is displayed, and figures are put into the built page. For instance the example :doc:`/gallery/lines_bars_and_markers/simple_plot` example is generated from :file:`/examples/lines_bars_and_markers/simple_plot.py`, which looks like: .. code-block:: python """ =========== Simple Plot =========== Create a simple plot. """ import matplotlib.pyplot as plt import numpy as np # Data for plotting t = np.arange(0.0, 2.0, 0.01) s = 1 + np.sin(2 * np.pi * t) # Note that using plt.subplots below is equivalent to using # fig = plt.figure and then ax = fig.add_subplot(111) fig, ax = plt.subplots() ax.plot(t, s) ax.set(xlabel='time (s)', ylabel='voltage (mV)', title='About as simple as it gets, folks') ax.grid() plt.show() The first comment block is treated as ReST_ text. The other comment blocks render as comments in :doc:`/gallery/lines_bars_and_markers/simple_plot`. Tutorials are made with the exact same mechanism, except they are longer, and typically have more than one comment block (i.e. :doc:`/tutorials/introductory/usage`). The first comment block can be the same as the example above. Subsequent blocks of ReST text are delimited by a line of `###` characters: .. code-block:: python """ =========== Simple Plot =========== Create a simple plot. """ ... ax.grid() plt.show() ########################################################################## # Second plot # =========== # # This is a second plot that is very nice fig, ax = plt.subplots() ax.plot(np.sin(range(50))) In this way text, code, and figures are output in a "notebook" style. Miscellaneous ============= Adding animations ----------------- There is a Matplotlib Google/Gmail account with username ``mplgithub`` which was used to setup the github account but can be used for other purposes, like hosting Google docs or Youtube videos. You can embed a Matplotlib animation in the docs by first saving the animation as a movie using :meth:`matplotlib.animation.Animation.save`, and then uploading to `matplotlib's Youtube channel `_ and inserting the embedding string youtube provides like: .. code-block:: rst .. raw:: html An example save command to generate a movie looks like this .. code-block:: python ani = animation.FuncAnimation(fig, animate, np.arange(1, len(y)), interval=25, blit=True, init_func=init) ani.save('double_pendulum.mp4', fps=15) Contact Michael Droettboom for the login password to upload youtube videos of google docs to the mplgithub account. .. _inheritance-diagrams: Generating inheritance diagrams ------------------------------- Class inheritance diagrams can be generated with the ``inheritance-diagram`` directive. To use it, provide the directive with a number of class or module names (separated by whitespace). If a module name is provided, all classes in that module will be used. All of the ancestors of these classes will be included in the inheritance diagram. A single option is available: *parts* controls how many of parts in the path to the class are shown. For example, if *parts* == 1, the class ``matplotlib.patches.Patch`` is shown as ``Patch``. If *parts* == 2, it is shown as ``patches.Patch``. If *parts* == 0, the full path is shown. Example: .. code-block:: rst .. inheritance-diagram:: matplotlib.patches matplotlib.lines matplotlib.text :parts: 2 .. inheritance-diagram:: matplotlib.patches matplotlib.lines matplotlib.text :parts: 2 .. _emacs-helpers: Emacs helpers ------------- There is an emacs mode `rst.el `_ which automates many important ReST tasks like building and updating table-of-contents, and promoting or demoting section headings. Here is the basic ``.emacs`` configuration: .. code-block:: lisp (require 'rst) (setq auto-mode-alist (append '(("\\.txt$" . rst-mode) ("\\.rst$" . rst-mode) ("\\.rest$" . rst-mode)) auto-mode-alist)) Some helpful functions:: C-c TAB - rst-toc-insert Insert table of contents at point C-c C-u - rst-toc-update Update the table of contents at point C-c C-l rst-shift-region-left Shift region to the left C-c C-r rst-shift-region-right Shift region to the right .. TODO: Add section about uploading docs .. _ReST: http://docutils.sourceforge.net/rst.html .. _Sphinx: http://www.sphinx-doc.org .. _documentation: http://www.sphinx-doc.org/contents.html .. _`inline markup`: http://www.sphinx-doc.org/markup/inline.html .. _index: http://www.sphinx-doc.org/markup/para.html#index-generating-markup .. _`Sphinx Gallery`: https://sphinx-gallery.readthedocs.io/en/latest/ .. _references: http://www.sphinx-doc.org/en/stable/markup/inline.html .. _`numpy documentation howto`: https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt