When I build the documentation locally, I see:

When it builds on RTD, the result is:

The only error or warning in the build log is:
copying static files... WARNING: html_static_path entry '/home/docs/checkouts/readthedocs.org/readthedocs/templates/sphinx/_static' does not exist
So I have no idea what might be causing this.
I think you need to mark the option to install your project inside the virtualenv https://docs.readthedocs.io/en/latest/faq.html#can-i-document-a-python-package-that-is-not-at-the-root-of-my-repository
I've tried that, but installing the project in a virtual environment fails because it can't install scipy:
Running scipy-1.1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-wlwgiltd/scipy-1.1.0/egg-dist-tmp-yp4yf4ya /tmp/easy_install-wlwgiltd/scipy-1.1.0/setup.py:375: UserWarning: Unrecognized setuptools command, proceeding with generating Cython sources and expanding templates warnings.warn("Unrecognized setuptools command, proceeding with " Traceback (most recent call last): File "/home/docs/checkouts/readthedocs.org/user_builds/epifx/envs/latest/lib/python3.5/site-packages/setuptools/sandbox.py", line 157, in save_modules yield saved File "/home/docs/checkouts/readthedocs.org/user_builds/epifx/envs/latest/lib/python3.5/site-packages/setuptools/sandbox.py", line 198, in setup_context yield File "/home/docs/checkouts/readthedocs.org/user_builds/epifx/envs/latest/lib/python3.5/site-packages/setuptools/sandbox.py", line 248, in run_setup DirectorySandbox(setup_dir).run(runner) File "/home/docs/checkouts/readthedocs.org/user_builds/epifx/envs/latest/lib/python3.5/site-packages/setuptools/sandbox.py", line 278, in run return func() File "/home/docs/checkouts/readthedocs.org/user_builds/epifx/envs/latest/lib/python3.5/site-packages/setuptools/sandbox.py", line 246, in runner _execfile(setup_script, ns) File "/home/docs/checkouts/readthedocs.org/user_builds/epifx/envs/latest/lib/python3.5/site-packages/setuptools/sandbox.py", line 47, in _execfile exec(code, globals, locals) File "/tmp/easy_install-wlwgiltd/scipy-1.1.0/setup.py", line 474, in <module> File "/tmp/easy_install-wlwgiltd/scipy-1.1.0/setup.py", line 450, in setup_package ImportError: No module named 'numpy'
I'm not sure about that, putting it the requirements.txt doesn't work? If it is for a C dependency, you can see https://docs.readthedocs.io/en/latest/faq.html#i-get-import-errors-on-libraries-that-depend-on-c-modules
You may try conda too https://docs.readthedocs.io/en/latest/conda.html
Thanks, I'll try that out. I'm confused though, the documentation did build correctly until (somewhat) recently:
https://epifx.readthedocs.io/en/0.5.4/getting_started.html#forecast-summaries
Edit: the above version of the docs were built without installing into a virtual environment.
No, removing numpy and scipy from install_requires and installing into a virtualenv doesn't fix this, the autoclass content is still missing and there are no warnings or errors apart from static files one noted in my original report.
The last known-good build was on October 25, 2017:
https://readthedocs.org/projects/epifx/builds/6179336/
Since that build, the only changes to build/configuration files (such as setup.py and the Spinx configuration file) were to bump the version number from 0.5.5 to 0.5.6.
Edit: I managed to get the autoclass documentation to build correctly by setting "Sphinx==1.5.3" in my (RTD-specific) requirements.txt file. So this might be a Sphinx bug? Although the Sphinx issues that appear relevant (e.g., this one) have all been fixed in Sphinx 1.7.5, so I don't know why it only works on RTD with an older version of Sphinx.
Edit 2: The docs build fine with Sphinx 1.7.5 on my own machine. This issue appears to only affect classes that inherit from imports that are mocked on RTD, but when I uninstall the relevant packages in my local virtualenv, Sphinx 1.7.5 still produces the correct documentation. I'm thoroughly confused.
Edit 3: I misread the RTD build log. This is a bug present in Sphinx 1.7.4 (as used by RTD) and fixed in Sphinx 1.7.5. So until RTD updates to Sphinx 1.7.5, I need to use an older version of Sphinx without this bug, such as 1.5.3. Thanks for your patience and assistance!
Would you like me to close this bug report, since it's caused by a bug in Sphinx?
Thanks for finding the root of the problem, I think we can keep this open till we update the default Sphinx version, btw, you can pin to a recent version of Sphinx too.
No worries. And yes, good point about pinning a newer version of Sphinx.