Read the Docs Overview
In 2019 we migrated the HTCondor Manual from our old LaTeX format into the Sphinx documentation generator using the reStructuredText format. We will also be hosting it on Read the Docs. The manual can be found here:
- Install Python (https://www.python.org/downloads, or you system package manager). You must install Python 3+. We no longer support Python 2.
- Install Sphinx and related support packages. The recommended way to install Sphinx is via `pip`, and we recommend using our pinned dependencies:
pip3 install --user -r docs/requirements.txt
- Install pandoc. On RHEL, for example:
sudo yum install pandoc
- Install the HTCondor Python bindings.
This could be via
pip(make sure you get the right version, e.g.
pip3 install htcondor==8.8.1), or by editing your
PYTHONPATHenvironment variable to point at the packages in your HTCondor build. For example (replacing
<htcondor-release-dir>with your local release directory path):
htcondorversion read out of
CMakeLists.txt, and the package versions in
- If you're on Python <= 3.4 (editorial note: why?!), install the
pip3 install --user pathlib
- [Optional] Install https://pypi.org/project/sphinx-autobuild/. This is useful if you're making lots of quick edits to the manual and expect to build it many times.
pip3 install --user sphinx-autobuild
Building and previewing the manual locally
- The manual pages exist in our git repository under the
- Each top-level section of the manual has a corresponding subdirectory with the same name. For example, all the content for "Overview" is under
/docs/overview, the content for "User's Manual" is under
/docs/users-manual, and so on.
- Each page of the manual has a corresponding file with the same name and a .rst extension. For example, the content for the "Overview > Exceptional Features" page is in
- To make a local build of the manual, go to your
/docsfolder and run:
- To preview your build, open a web browser and go to the following URL:
- To clean your local build, go to your
/docsfolder and run:
Using sphinx-autobuild to build and preview
Instead of the instructions in the previous section, go to
/docs and run
sphinx-autobuild . _build/html
localhostwebserver hosting the docs. Leave this program running:
sphinx-autobuildwill watch the docs source tree for changes and rebuild when it detects changes (you may still need to manually reload the page inside your web browser, but it will usually force a refresh by itself).
Different versions of the manual
- Read the Docs allows us to host multiple versions of the manual. We'll have two separate versions: "latest" (equivalent to Development Release) and "stable" (equivalent to Stable Release).
- To make edits to the latest version, make your changes on the master branch.
- To make edits to the stable version, make your changes to the V8_8-branch (or the appropriate V8_8_X-branch if making your changes after code freeze)
The manual now uses the reStructuredText (rST) format, which is similar to Markdown markup but considerably more powerful. A helpful reference to reStructuredText is available here:
In addition, the new manual also uses the Sphinx documentation generator. Sphinx does many useful things such as:
- Converts reStructuredText files into HTML websites, PDF, EPUB and man pages.
- Extends rST to provide more complex inline widgets such as tables of contents, syntax-colored code blocks, internal links and references,
- Automatic indices, search and language-specific module indices
- Provides a powerful API for writing custom extensions
A full Sphinx reference is available here:
This section provides some markup style guidelines, as well as information about how we use both built-in and custom tools.
Section titles are very fluid in rST and there are many different ways to make them. To keep things as consistent as possible, try to use the following:
Page titles get underlined with the = symbol ============================================ Section titles get underlined with the - symbol ----------------------------------------------- Subsection titles get underlined with the ' symbol ''''''''''''''''''''''''''''''''''''''''''''''''''
The rST format is very sensitive to indentation. Paragraphs and other blocks of text are expected to be left-aligned. Indenting a block by any amount of whitespace (compared to the preceding block) causes it to get indented.
This is a top-level block of text. It will appear aligned to the left-most side of the page. This paragraph is indented by one space. Even though it's only a single space, it will render as a full first-level indent. This paragraph is indented by one more space than the one above it. As a result it will render as a second-level indent. This time I've indented a block by two more spaces the one above it. It doesn't matter that this is inconsistent with the single-space indents above. This block will render as a third-level indent. Back to the top level! This block is indented by 12 spaces. However, as with the previous examples, the amount of whitespace doesn't matter. Because it's the first indented block compared to the preceding block, it will only render as a first-level indent.
Linking to gittrac tickets
Use the following syntax to automatically link to a gittrac ticket, where #### is the number of the ticket:
Adding index entries
To add a basic index entry, use the following syntax:
:index:`Name of index entry`
If you want your index entry to appear under a parent entry, the syntax is a little more complicated:
:index:`Name of index entry <single: Name of index entry; Name of parent entry>`
Linking to internal documents
To add a link to an internal document, the syntax looks like
:doc:`/path/to/page-title`. For example, to link to the Overview > Exceptional Features section, add the following:
By default, the link text will be the name of the page. If you want to add custom text, it looks something like the following:
:doc:`Here is my custom text link </overview/exceptional-features>`
Linking to subsections within documents
You can also easily add links to subsections within documents. Whenever a section or subsection is defined using the correct section title syntax (see "Section Titles" above), Sphinx will automatically make the an HTML anchor so you can link directly to it. Use the following syntax:
For example, to link to the "Start an Annex" subsection on the Annex User's Guide page, use the following:
:ref:`cloud-computing/annex-users-guide:start an annex`
By default, Sphinx will use the name of the section as the link text. You can override this with the following syntax:
:ref:`My custom link text goes here<path/to/document:section title>`
Documenting Python Objects
Python "objects" (classes, methods, free functions, enums, anything) are documented via
sphinx-autodoc (https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html). "Docstrings" for these objects are written directly into the Python bindings C++ source code, are embedded into the Python library during the HTCondor build process, and are then read by Sphinx during the manual build.
As an example, a method declaration (adding a method to a class) looks like this in the C++ source code:
.def("queue_with_itemdata", &Submit::queue_from_iter, R"C0ND0R( Submit the current object to a remote queue. :param txn: An active transaction object (see :meth:`Schedd.transaction`). :type txn: :class:`Transaction` :param int count: A queue count for each item from the iterator, defaults to 1. :param from: an iterator of strings or dictionaries containing the itemdata for each job as in ``queue in`` or ``queue from``. :return: a :class:`SubmitResult`, containing the cluster ID, cluster ClassAd and range of Job ids Cluster ID of the submitted job(s). :rtype: :class:`SubmitResult` :raises RuntimeError: if the submission fails. )C0ND0R", (boost::python::arg("self"), boost::python::arg("txn"), boost::python::arg("count")=1, boost::python::arg("itemdata")=boost::python::object()) )
C0ND0Rfor the docstring itself. The syntax is described here: https://sphinx-rtd-tutorial.readthedocs.io/en/latest/docstrings.html
.rst source that would embed this docstring, prettily-formatted, in the manual looks like
.. autoclass:: Submit .. automethod:: queue .. automethod:: queue_with_itemdata .. automethod:: expand .. automethod:: jobs .. automethod:: procs .. automethod:: itemdata .. automethod:: getQArgs .. automethod:: setQArgs .. automethod:: from_dag
.. auto<something>::are Sphinx directives provided by
sphinx-autodocwhich are replaced by the autodoc-formatted descriptions. So this block produces all of the documentation for the
When documenting a new thing in the bindings, you must also add an appropriate
.. auto<something>:: in the appropriate
Publishing the manual onto Read the Docs
- Currently Mark or Josh has to login to Read the Docs to manually push any changes.
Different versions of the manual
- To make changes to the devel/latest version of the manual, put all your changes in the master branch.
- To make changes to the stable version of the manual, you need to add a tag called "stable" to the commit in V8_8-branch that contains the changes you want. To update the stable tag to a new commit, run the following:
git tag --delete stable git push --delete origin tag stable git tag stable git push origin stable
Generating man pages
- The files in
/docs/man-pageswill be the official source for our man pages going forward.
- Sphinx can generate the man pages automatically. They will get output by default to the
/docs/_build/manfolder. From the