-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Make the STABLE and LATEST constants overridable #4099
Conversation
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 looks useful. I definitely want to maintain backwards compat though. If the goal is to simply make it able to be changed with a setting, a much less invasive change would be to have the constants be able to read from a setting, instead of changing every instance of it.
readthedocs/builds/constants.py
Outdated
NON_REPOSITORY_VERSIONS = ( | ||
LATEST, | ||
STABLE, | ||
) |
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 looks like a good change. There is downstream code that depends on this -- so we should maintain backwards compatibility here. If there is a simple way to introduce this change so that it simply reads from the settings and sets the constants
value, it would be better.
We are currently shipping the following commit: Downside of this is that we cannot ship the two together IIRC because of circular dependencies and tests still has them hardcoded so can't test out of the box with a different value in settings. |
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.
Also echoing the need to move this back to constants for downstream.
Do you have any idea on how to make them configurable but still keep them in constants? I don't. |
@xrmx can you talk more about the reasons that italia@fc50de4 won't work? I don't think we're ready to commit to this PR's approach in all our downstream dependencies, but I could perhaps be convinced if shown why the simpler settings-based approach can't work. |
@ericholscher it will work on its own and we are currently using it. But i think that using plain settings for something that should be configurable would be cleaner. Anyway if you are fine with that approach I can update the PR. The smaller delta we have from upstream the better. |
Yea, I think that is a much easier change to make at least for now. We can talk about the larger one later. |
Makes the constants overridable from settings so that downstream can use different ones.
Updated PR as agreed. |
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 looks like a good change. Curious @xrmx what are y'all using for these versions instead of latest
and stable
?
@ericholscher roughly the same but in italian :) draft instead of latest and stable is the same. |
@agjohnson care to update review after different proposed implementation please? Thanks! |
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.
Thanks!
The new approach it's better to me. I think we are safe to merge this PR.
ping, we have a couple positive reviews, can we merge it please? |
This is ready to merge. I'm assigning this to myself to merge after the migration that it's taking place this weekend. |
@humitos any update? |
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.
Thanks!
@humitos thanks! |
Moving them to settings and making life easier for downstreams
that want to use different labels.