Skip to content

Add Ability to ask for latest Python 3.X runtime to build docs #7814

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

Closed
cooperlees opened this issue Jan 8, 2021 · 6 comments
Closed

Add Ability to ask for latest Python 3.X runtime to build docs #7814

cooperlees opened this issue Jan 8, 2021 · 6 comments
Labels
Feature New feature Needed: design decision A core team decision is required

Comments

@cooperlees
Copy link

Details

Expected Result

I'd love to be able to change my "Python Interpreter" to be latest 3.x as opposed to the current behavior of the stable version (which happens to be 3.7 it seems)

i.e. I wish to remove the following from my readthedocs.yml:

diff --git a/.readthedocs.yml b/.readthedocs.yml
index f92a6f7..5ca6231 100644
--- a/.readthedocs.yml
+++ b/.readthedocs.yml
@@ -16,7 +16,6 @@ formats:
   - epub
 
 python:
-  version: 3.7
   install:
     - method: pip
       path: .

image

  • e.g. Change this to latest Cpython 3.x

Actual Result

Today if we remove python.version 3.8 we go back to 3.7. I'd rather select to default to latest runtime please.

  • Main win, when 3.9 and then 3.10 come out it's one less thing I have to move to
@ericholscher
Copy link
Member

We really don’t want the python version to change when you haven’t specified one, if at all possible. A good, more explicit solution would be to have a “latest“ option, which would do this. I’m not sure we want to support this though, because it will make builds less stable and confuse most users who set it.

@cooperlees
Copy link
Author

Totally agree with being explicit. If that didn’t come across I’d love an explicit way to opt into this behavior. I was expecting in the web ui to set that behavior, but love it in the yaml even more!

I prefer the break more forward fix CI life and would rather not have to watch some feed to always update the version once you support it.

@stsewd
Copy link
Member

stsewd commented Jan 11, 2021

Totally agree with being explicit. If that didn’t come across I’d love an explicit way to opt into this behavior. I was expecting in the web ui to set that behavior, but love it in the yaml even more!

This was possible some time ago, but we changed it, I think this was changed when we introduced python 3.8 to avoid breaking builds. #6653

From the description of the PR the original plan was to update it to use the latest available version eventually. I think we are good to do that now. @ericholscher what do you think?

@stsewd stsewd added the Needed: design decision A core team decision is required label Jan 11, 2021
@ericholscher
Copy link
Member

I think this goes into our larger discussion about how to manage requirements and not break builds. I still think "always build with the same versions of dependencies going forward" is the best default. We can then give users an option to configure another way of handling it (eg. always use the latest version of all dependencies, eg. run pip install -U).

@cooperlees
Copy link
Author

My main ask here is that user can choose to stay with latest cpython here automatically once read The Docs deems it ready. I feel pip doc building dependencies should be controlled by Read The Docs code / automation.

My main pain here was I moved https://github.com/pypa/bandersnatch to be >=3.8 only and read the docs failed due to being built with 3.7 to generate the API docs.

@humitos humitos added the Feature New feature label Jan 12, 2021
@stsewd
Copy link
Member

stsewd commented Sep 29, 2021

This is now possible with our new config options

#8453
https://github.com/readthedocs/readthedocs.org/pull/8478/files

Docs to be updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New feature Needed: design decision A core team decision is required
Projects
None yet
Development

No branches or pull requests

4 participants