-
Notifications
You must be signed in to change notification settings - Fork 35
Deprecate the custom RTD builders (except local media) #88
Conversation
- Uses default Sphinx builders instead (except for zipped media) - Use a Sphinx extension and events to add additional JS/CSS files - We should probably increment a major version for releasing this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is definitely a solid improvement, but it's backwards incompatible in an annoying way. I don't really know how to handle shipping it without breaking things, but it's definitely going to break something.
@@ -18,16 +18,17 @@ http://docs.readthedocs.org/en/latest/canonical.html | |||
|
|||
<link rel="stylesheet" href="{{ rtd_css_url }}" type="text/css" /> | |||
|
|||
<script type="text/javascript" src="{{ pathto('_static/readthedocs-data.js', 1) }}"></script> | |||
<script type="application/json" id="READTHEDOCS_DATA">{{ rtd_data | tojson }}</script> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little worried about this possibly breaking things that users are depending on (eg. they are including this file themselves to get our data back out). I wonder if we should continue to build the file but not link it, at least for some time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While it is possible that this will break things for some users, I don't think it will do so in a systemic way for many users (say by breaking a theme). We maintain the global variable which was set in readthedocs-data.js
for backwards compatibility and given that some page and suffix data was modified in that global below, nobody could correctly read the variable without parsing both the HTML and JS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, but only the page
was set in the HTML instead of the JS, so if they just were reading eg. the project or version, it would have worked fine. I think continuing to ship the file for now seems easy enough and minimal risk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will see if it's possibly to produce the file from an extension rather than from a builder. When producing the file, perhaps I'll add a note into the file noting that it is deprecated and will be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't spend too much time if it's a pain, but shipping static files is pretty standard for extensions, so I think it should be simple enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just want to use the same function where the inline JSON is generated so they're the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's actually a little difficult to do this in a consistent way. I might skip it.
- I want to write that file, but only once per build
- I need the context which is in the
html-page-context
but I don't want to rewrite the same file for every page. - I can't just detect if the file exists because the file might be there if the environment is re-used.
readthedocs_ext/readthedocs.py
Outdated
ONLINE_BUILDERS = [ | ||
'readthedocs', 'readthedocsdirhtml', 'readthedocssinglehtml' | ||
'html', 'dirhtml', 'singlehtml' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am worried this is going to break some of our users customizations, eg something like this: https://github.com/Invoca/developer-docs/blob/a1b05592d95fbdfee2f2360a3c2da9c427669c4c/source/conf.py#L158
I didn't see a ton of these in a GH search, and it's never been a properly supported way of finding out if you're running on RTD, but it's definitely going to break :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the alternative? If we want to use the regular Sphinx builders then people depending on us using a different builder are going to have something break on them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another thing, sphinx creates tags with the name of the builder, users may be relying on that too (but probably this one is easy to fix). I'm on the phone, but I'll link to the issue and sphinxs docs in the morning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-only
The format and the name of the current builder (html, latex or text) are always set as a tag 4. To make the distinction between format and name explicit, they are also added with the prefix format_ and builder_, e.g. the epub builder defines the tags html, epub, format_html and builder_epub.
These standard tags are set after the configuration file is read, so they are not available there.
And users already depending on that readthedocs/readthedocs.org#4765 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to perhaps we could deprecate the builders and roll using the stock ones out slowly. However I think we want to use the regular builders and not custom ones as much as possible.
The users in the linked issue should be ok since they're using .. only :: builder_html or readthedocs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, I think there's no way around breaking this, but perhaps we should communicate it prior to doing it, but I don't know a great way to communicate it, since most users won't care and it's super deep and technical.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there's a great way to communicate it either. It was never exactly supported so trying to tell people that the undocumented thing they were relying on is changing is hard. One possibility if we're really concerned about this is to keep the custom builders and have a feature flag that determines whether somebody uses the stock builders or the custom ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, I think we can probably just ship it and see what happens.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to get this merged and shipped 👍
Sounds good. After merging, there's a few steps:
|
We could ship this this week, if you're ready @davidfischer |
Just a note here, when rebasing this PR, we need to make sure we are including the change from #85 |
It's ready and I'll try to merge the changes from #85 into here. |
RemovesDeprecates the custom RTD-specific builders (readthedocs
,readthedocsdirhtml
, andreadthedocssinglehtml
) in favor of just using regular Sphinx builders.In the 2.x branch, Sphinx made some changes (sphinx-doc/sphinx#6741) to their searchtools that caused problems with users who opt-out of Read the Docs' search improvements and use the dirhtml builder.
The changes in this PR:
UsesFavors using default Sphinx builders instead (except for zipped media). Other extensions and added custom files will work on the default Sphinx builders.This will require a simultaneous release on RTD to use the default buildersAt a later date, we will add a feature flag to use default Sphinx builders instead of the custom builders but that change will be small (eg. here).majorminor version of this package for releasing thisRefs: pallets/click#1513, pallets-eco/wtforms#599