Skip to content

Cleanup how path are handled (dev/production) #4119

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
humitos opened this issue May 21, 2018 · 3 comments
Closed

Cleanup how path are handled (dev/production) #4119

humitos opened this issue May 21, 2018 · 3 comments
Labels
Accepted Accepted issue on our roadmap Bug A bug Improvement Minor improvement to code
Milestone

Comments

@humitos
Copy link
Member

humitos commented May 21, 2018

There are some places where we are checking for the DEFAULT_PRIVACY_LEVEL to decide things that are not related to the privacy level but more related to the site/instance we are running (community/corporate site).

Example, get_production_media_path is using this to decide if we need to use MEDIA_ROOT or PRODUCTION_MEDIA_ARTIFACTS: https://github.com/rtfd/readthedocs.org/blob/84cefc40f00083cbc74a473ffb4ef890294159a1/readthedocs/projects/models.py#L402

Besdies, I think that get_production_media_path is not a good name for this method and shouldn't have the production word on it. Example of usage of this: https://github.com/rtfd/readthedocs.org/blob/84cefc40f00083cbc74a473ffb4ef890294159a1/readthedocs/search/utils.py#L22-L27

Why we can't use just the same method full_json_path without worry about where we are each time that method is called?

There is a get_production_media_url also with the same problem.

Also, here https://github.com/rtfd/readthedocs.org/blob/84cefc40f00083cbc74a473ffb4ef890294159a1/readthedocs/projects/views/public.py#L185 we have harcoded /prod_artifacts and we should find a way to get it from a common place.

Related: https://github.com/readthedocs/readthedocs-ext/pull/128

@humitos humitos added this to the Cleanup milestone May 21, 2018
@ericholscher ericholscher added Improvement Minor improvement to code Bug A bug labels May 30, 2018
@stale
Copy link

stale bot commented Jan 10, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Status: stale Issue will be considered inactive soon label Jan 10, 2019
@stsewd stsewd added Accepted Accepted issue on our roadmap and removed Status: stale Issue will be considered inactive soon labels Jan 10, 2019
@humitos
Copy link
Member Author

humitos commented Jan 25, 2020

This checks have changed a lot now we are using the django storage to get manage them. Although, there are still some places that we can refactor or remove completely this check. Some code will be removed in #6535 or similar.

@stsewd
Copy link
Member

stsewd commented May 7, 2020

We don't have this code anymore, and we have everything in storage now.

@stsewd stsewd closed this as completed May 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Accepted Accepted issue on our roadmap Bug A bug Improvement Minor improvement to code
Projects
None yet
Development

No branches or pull requests

3 participants