Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate version selector dynamically via JavaScript #179

Closed

Conversation

humitos
Copy link
Contributor

@humitos humitos commented Jul 23, 2024

Note this is just a proof of concept to start the conversation.

While working on the idea to generate the version/language selectors and combine them with the data fetched from Read the Docs API, I realized that if we are migrating only one version to Read the Docs and using a proxy to serve it at the official docs.python.org domain, there is no need to use a different version/language selector at all --since all the URLs will be the same and all the JavaScript logic will be the same. The proxy will do the magic to redirect to Read the Docs only the versions configured in the proxy 1.

However, since when building on Read the Docs the variables VERSIONS and LANGUAGES are not passed, we need to populate them dynamically with JavaScript when the page is served.

ToDo


I'm opening a PR here to show what I'm thinking and discuss if this is the approach we want to follow. BTW, the code is not tested. I just wrote it as an example to show what I'm thinking is the direction.

cc @hugovk

Related:

Footnotes

  1. Once all the versions/languages are migrated to Read the Docs, we won't require the release-cycle.json nor other file to populate the LANGUAGES variable because this data will come from Read the Docs Addons API.

_Note this is just a proof of concept to start the conversation._

While working on the idea to generate the version/language selectors and combine
them with the data fetched from Read the Docs API, I realized that if we are
migrating only _one_ version to Read the Docs and using a proxy to serve it at
the official `docs.python.org` domain, there is no need to use a different
version/language selector at all --since all the URLs will be the same and all the
JavaScript logic will be the same. The proxy will do the magic to redirect to
Read the Docs _only_ the versions configured in the proxy [^1].

However, since when building on Read the Docs the variables `VERSIONS` and
`LANGUAGES` are not passed, we need to populate them dynamically with JavaScript
when the page is served.

**ToDo**:

- Populate `all_languages` in the same way.
  Do we have a JSON file from where we can populate the `LANGUAGES` variable?
- Move this `switchers.js` file to
  https://github.com/python/cpython/tree/main/Doc/tools/static

----

I'm opening a PR here to show what I'm thinking and discuss if this is the
approach we want to follow. BTW, the code is not tested. I just wrote it as an
example to show what I'm thinking is the direction.

Related:
- python/python-docs-theme#193
- python/docs-community#5

[^1]: Once all the versions/languages are migrated to Read the Docs, we won't
require the `release-cycle.json` nor other file to populate the `LANGUAGES`
variable because this data will come from Read the Docs Addons API.
@humitos
Copy link
Contributor Author

humitos commented Jul 23, 2024

because this data will come from Read the Docs Addons API

We will be using the work we've done at python/cpython#116966 and python/cpython#119541 only, without needing anything else to generate these selectors.

@humitos
Copy link
Contributor Author

humitos commented Jul 23, 2024

Also also, if we want to generate these selectors at build time, the PR that @AA-Turner wrote python/python-docs-theme#193 should work out of the box on Read the Docs without issues. In that case, we should disable the custom rtd_switchers.js we are injecting on Read the Docs.

@humitos
Copy link
Contributor Author

humitos commented Jul 23, 2024

I'm going to close this PR and continue writing my thinking at python/python-docs-theme#193. I'm sorry for the confusions I could have caused here 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant