Description
We currently use a homegrown solution to generate our documentation. While it works fine, it is a little inflexible and requires some ridiculous hoops to add new pages: (1) create the new page, (2) add the page to the siteindex, and (3) update the meta data of both the page before and page after. I'd like to eliminate step 3 which is redundant when we have the siteindex. But the current implementation renders each page individually so info about next and previous pages isn't available unless it is stored in the given page. The existing siteindex just serves as a dumb, static list of all pages. If you forget to add or delete a page from the siteindex, everything still works except that the siteindex is wrong. Most site generators use the siteindex to build a global context which provides each page with its next/previous page links, etc.
Rather than "reinventing the wheel" we should just use an existing solution. mkdocs looks like the most reasonable solution to me. It appears to be under active development (unlike a few of my false starts), it has a set of goals which align with our needs, it uses Python-Markdown under the hood, and has configurable support for Python-Markdown extensions. In fact, with an updated template it would almost be a drop-in replacement. It is also supported out-of-the-box by readthedocs.
There are a few problems though:
- mkdocs does not support the latest version of Python-Markdown as it still supports Python 2.6 (we dropped support in PM v 2.5). So we need to wait for mkdocs' issue 165 to be resolved.
- mkdocs is using the old (special) treatment of shortened extension names which is currently pending deprecation (see 2.5 release notes). A minor refactor of its
convert_markdown
function is in order (see below). - A way to configure extensions should be implemented as the old way (appending to extension name wrapped in parentheses) is also pending deprecation. Perhaps something similar to the new
--extensions-config
command line option would serve well if implemented as part of mkdocs config file.
A refactor of the convert_markdown
function might include the following:
- As previously mentioned
'toc' => 'markdown.extensions.toc'
, etc. Account for duplicate extensions (the user may have specified an extension in their config which is also in the default list -- perhaps use a set?)This is not an issue as long as the default list is loaded first. the last instance to be loaded wins. Should probably add some tests to PM for this (and check for what happens when an extension deletes an existing processor when the previously loaded instance already deleted it).- Use
md.toc
rather than doing its own thing- but that requires the TOC extension to always assign the toc toTOC refactor has been done and will be released in 2.6. So this change depends on markdown>=2.6md.toc,
not just when no TOC Marker is found in the document (remember, a doc author may have placed their own toc marker in the doc also). Also TOC extension should register and 'reset' themd.toc
. A refactor of the TOC extension needs to happen here first.