We are happy to announce that a new flyout menu is now available as part of the ongoing beta test for our latest project, Read the Docs Addons.

After much hard work, we are excited to begin testing this feature with more projects. We have previously been testing other documentation features as part of this ongoing beta, but the flyout menu is by far the most prominent feature yet.

This post was updated on Oct 10 to reflect all of the changes to installed dependencies

We are announcing the deprecation of automatic installation of several key project dependencies, and builds will no longer install older documentation tool versions by default.

We are announcing the deprecation of build.image config key in favor of build.os. Read the Docs will start requiring a build.os config key for all projects in order to build documentation successfully. We will start failing builds for projects not using “build.os” in their config file on October 16, 2023.

We understand this change will affect many of our users, so we have a timeline to communicate this deprecation to our users effectively.

Read the Docs used to pre-install common scientific Python packages like scipy, numpy, pandas, matplotlib and others at system level to speed up the build process. However, with all the work done in the Python ecosystem and the introduction of “wheels”, these packages are a lot easier to install via pip install and these pre-installed packages are not required anymore. If you have Apt package dependencies, they can be installed with build.apt_packages.

With the introduction of our new “Ubuntu 20.04” and “Ubuntu 22.04” Docker images, we stopped pre-installing these extra Python packages and we encouraged users to install and pin all their dependencies using a requirements.txt file. We have already stopped supporting “use system packages” on these newer images.

Historically, Read the Docs has created an auto-generated index.html file with minimal instructions about how to setup the project correctly when your build didn’t output this file. This auto-generated file has confused more users than it has helped because the behavior on Read the Docs was different from the behavior on their local environment.

To better onboard users, we have deprecated the auto-creation of index.html files on Read the Docs projects. We will now check for an index.html file at the end of the build, and fail it with a clear message of the problem if there is no index.html file in the top level of your output directory.

Historically Read the Docs has created a conf.py file for Sphinx projects and a mkdocs.yml file for MkDocs projects that don’t provide one, to make onboarding easier. This has been confusing a lot our users in different ways and we will remove the auto-creation of a default Sphinx/MkDocs configuration file for projects that don’t have one on August 28th. To avoid unexpected behavior or your documentation builds failing, you should add a configuration file to your project by this date.

The auto-creation of a default configuration file will be completely removed on August 28th. Add a conf.py/mkdocs.yml to your projects before this date to avoid unexpected build failures.

Starting on July 18, 2023 PyPy3 will be removed as an option to build documentation on Read the Docs.

This feature was introduced as an alternative to make Sphinx build faster. However, we found there are no projects building their documentation with PyPy3 and we decided to remove its support to simplify our product and reduce development maintanence.

Starting on August 7, 2023 all new projects imported on Read the Docs will install only sphinx, mkdocs and readthedocs-sphinx-ext as “core requirements”. The default behavior will be to install the latest version of these requirements.

Note that previously Read the Docs was installing also jinja, sphinx-rtd-theme, pillow, mock, alabaster, commonmark and recommonmark specifying particular versions depending on different factors that were confusing for users and hard to debug.

We are announcing a new requirement for all builds to use our configuration file version 2. This announcement deprecates builds without a configuration file, as well as version 1 of our configuration file.

Read the Docs will start requiring a .readthedocs.yaml configuration file for all projects in order to build documentation successfully. We will stop supporting builds without explicit configuration, because this creates implicit dependencies that users aren’t aware of. We plan to start failing builds not using configuration file version 2 on September 25, 2023.

We are happy to announce a new beta feature that allows users to override the Read the Docs build process completely. We previously talked about executing custom commands in-between the Read the Docs build process. That approach is not sufficient for projects with a heavily customized build process, or those that want to use a different documentation tool like Pelican, Docsify and Docusaurus for their documentation. Some of which were not able to use our platform at all. Until now! We have good news for them!

The new configuration file option build.commands allows projects to only execute exactly the commands they want. No more. No less. This means that Read the Docs won’t execute any of the default commands behind the scenes. You have 100% control over the build process.

Read the Docs allows you to keep your documentation up to date in a simple way, by triggering a new build each time developers push a git repository. Depending on your workflow, there could be situations where multiple pushes are done during a short time window. This causes a situation where you have to wait a long time for a build that will be immediately overwritten.

To avoid waiting for those builds to be executed, we implemented a new feature to cancel these useless builds and only execute the latest one. This considerably improves the user experience and also reduces resource costs and energy waste.

Read the Docs generates a lot of data. We are the largest documentation platform out there, with hundreds of thousands of projects using our product every day to host their documentation. This data includes simple things like number of users, builds using a particular Docker image, as well as more interesting ones like pageviews or Python dependencies installed via a requirements.txt file. We didn’t collect this data in a systemic way during the first 10 years of our existence.

Last year, with the growth of our product and the team, plus the CZI grant we received, we started asking ourselves some questions that we couldn’t answer with the data we had. We decided to start working on a project to collect relevant data to answer a large number of questions about how people use our service.

We are happy to announce a new feature to specify user-defined build jobs on Read the Docs. If your project requires custom commands to be run in the middle of the build process, they can now be executed with the new config key build.jobs. This opens up a complete world full of new and exciting possibilities to our users.

If your project has ever required a custom command to run during the build process, you probably wished you could easily specify this. You might have used a hacky solution inside your Sphinx’s conf.py file, but this was not a great solution to this problem.

We are excited to announce that our API v3 has reached a stable release, and is now available for all Read the Docs users. Since we announced the API v3 beta, we have been adding extra functionality and bug-fixing minor issues based on user feedback.

The new API v3 is not a fully replacement (yet!) of API v2, but we highly recommend using API v3 for all the new integrations. API v2 will be deprecated soon, though we don’t have a firm timeline for deprecation. We will alert users with our plans when we do.

In the past year, we’ve been having issues when building projects’ documentation using conda. Our build servers were running out of memory and failing projects’ builds. Read the Docs has this memory constraint to avoid misuse of the platform, causing a poor experience for other users.

Our first solution was a dedicated server for these kind of projects. We would manually assign them to this server on user requests. This workaround worked okay, but it involves a bad experience for the user and also us doing a manual step each time. Over time, we hit again the same issue of OOM, even giving all the memory available to one project to build its documentation. After some research, we found that this is a known issue in the conda community and there are some different attempts to fix it (like mamba). Unfortunately, none of them became the standard yet and the problem is still there.

In the last months, we have been working on making our API better. Considering the limitations of our current REST API v2, we decided to make a bigger step forward and create a new API v3, putting the focus on the use cases we heard about from existing users.

Compared to API v2, our new API v3 has some big differences that make it more user-friendly and useful.