WIP: Documentation: provide a version dropdown menu and change theme #3437
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The documentation of cime is starting to diverge on the various
important branches (master, maint-5.6, and ufs_release_v1.0). This PR,
along with similar PRs for maint-5.6 and ufs_release_v1.0, and some
changes to the gh-pages branch, support having versioned documentation,
with a dropdown menu. This also changes the documentation theme to a
theme that supports this version dropdown. Note that I have brought the
necessary theme in as a subtree, because I'm not aware of an
out-of-the-box sphinx theme that provides this support (see below for
more details).
At a high level, the way the versioned documentation works is to have
separate subdirectories in the gh-pages branch for each version of the
documentation we want to support. There is then a bit of JavaScript code
which uses a json file in the gh-pages branch to determine which
versions exist and how these should be named in the dropdown menu. This
changes the documentation build process slightly; I will update the wiki
to reflect these changes.
Note that this implementation is borrowed from
ESCOMP/CISM-wrapper#23, which in turn is a
slight modification of an implementation provided by @MNLevy for the
MARBL documentation, which in turn borrowed from an implementation put
together by Unidata (credit where credit is due).
As mentioned above, I am not aware of out-of-the-box support for a
version pull-down in out-of-the-box sphinx themes (though the last time
I looked was in Fall, 2018, so there may be something available
now). However, support for a version dropdown exists in an open PR in
the sphinx readthedocs theme repository:
readthedocs/sphinx_rtd_theme#438. I have brought
this theme in as a subtree to simplify the process of building the
documentation (avoiding the need for a separate pip install of the
theme). In the long-term, I am a little concerned about using this theme
that isn't showing any signs of being merged to the main branch of the
readthedocs theme, but this has been working for us in other projects
for the last 2 years, so I feel this is a reasonable approach in the
short-medium term.
Specifically, I added the subtree with the following:
Search functionality was broken in this version of the theme, so I also
cherry-picked a commit to fix search (from
readthedocs/sphinx_rtd_theme#672):
@mvertens and I then made the various other changes that you can see in
doc/source
in this PR, which mainly borrowed fromESCOMP/CISM-wrapper#23.
A few changes were also needed in the gh-pages branch:
A
versions
directory was introduced at the top level, withsubdirectories for each documentation version we want to support. We
are using the convention that these subdirectories should have names
that match the corresponding cime branches, to avoid uncertainty.
A top-level index.html page was introduced that redirects to the
master version of the documentation:
Other than those files and an empty
.nojekyll
file, everything elsewas removed from the top level directory of the documentation.
In the versions directory, we also introduced a
versions.json
file. This lists the versions and provides a mapping between directory
names and the names used in the pull-down menu:
the documentation build script. Thus, it is safe to remove the
contents of (e.g.)
versions/master/
before rebuilding thedocumentation for that version. The documentation build is done
similarly to before, but now providing a BUILDDIR argument to the make
command in order to build in the correct subdirectory. For example,
when building the documentation for master, you would provide
BUILDDIR=/path/to/cime_gh_pages_repo/versions/master/
.Test suite: none
Test baseline: n/a
Test namelist changes: none
Test status: bit for bit
Fixes none
User interface changes?: none
Update gh-pages html (Y/N)?: Y (already done)
Code review: