This does not exist. We need to add a tag to a commit that is before the merge commit of this PR, to trigger a build of a 3.1.0 version.

Should I revert, tag, and then revert the revert?

I guess just tagging should be fine to get some docs for 3.1.0.

A general problem is however is that these docs here build both Tutorial AND API docs.
And API docs are currently hardcoded to parse whatever is the latest on our pypi:
https://github.com/OpenMS/pyopenms-docs/blob/master/docs/requirements.txt#L9

So, if you now tag an older commit of pyopenms-docs as 3.1.0, and rebuild on RTD, you will get tutorials and ipynbs for 3.1.0 but API docs for latest. Unfortunately, even reverting would not solve this.
Only reverting, fixing the underlying issue, tagging, revert the revert might fix it.

A fix would involve running a pip install DURING the doc build, not before, based on the version that is present in the conf.py

hmm would this mean we would need to somehow check if available and fetch the python artifacts from our python whl job (instead of using pip with our pypi) and install them from the downloaded whl? also pinging @poshul for input

Yes, I think ideally, a successful run of pyopenms-wheels on develop (or a release tag/branch) would trigger a docs build with the same artifact (which should be uploaded to our pypi anyway, right?).

And a standalone docs build would use the latest build for the version specified in the conf.py.

Also the pyopenms version that is imported in the tutorial notebooks should be dynamic. Otherwise, if you open Binder for an old release tag, it would install the latest version instead. Currently everything is just working for nightlies (except that the non-API docs are kind of versioned.

I guess this could be incremented as well to 3.3.0dev. Maybe wait until the actual version was incremented in OpenMS