-
Notifications
You must be signed in to change notification settings - Fork 4.1k
chore: remove deprecated DEFAULT_FILE_STORAGE and STATICFILES_STORAGE… #37002
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
base: master
Are you sure you want to change the base?
chore: remove deprecated DEFAULT_FILE_STORAGE and STATICFILES_STORAGE… #37002
Conversation
Thanks for the pull request, @wgu-ram-chandra! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. Where can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
@@ -222,7 +222,6 @@ def get_env_setting(setting): | |||
# we need to run asset collection twice, once for local disk and once for S3. | |||
# Once we have migrated to service assets off S3, then we can convert this back to | |||
# managed by the yaml file contents | |||
STATICFILES_STORAGE = os.environ.get('STATICFILES_STORAGE', STATICFILES_STORAGE) |
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.
Since we are not expecting "STATICFILES_STORAGE" setting from the environment, this line can be removed. But little guidance on how to approach this greatly helps. Thanks!
1e6c7f8
to
9e61aa3
Compare
@holaontiveros, thanks for pointing that out! I realized that I mistakenly applied |
9e61aa3
to
fe30e7d
Compare
Sandbox deployment failed 💥 |
Sandbox deployment failed 💥 |
1 similar comment
Sandbox deployment failed 💥 |
Sandbox deployment failed 💥 |
Sandbox deployment failed 💥 |
cdfd345
to
0f55c9e
Compare
Sandbox deployment failed 💥 |
![]() The patch that might be involved: https://github.com/hastexo/tutor-contrib-s3/blob/main/tutors3/patches/openedx-common-settings I'm still seeing the same issue on the sandbox, I'll share an update once it's resolved! |
Sandbox deployment failed 💥 |
Sandbox deployment failed 💥 |
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.
@wgu-ram-chandra what's the impact on downstream production systems, if someone has DEFAULT_FILE_STORAGE or STATICFILES_STORAGE settings defined in their YAML config, I believe those will now get ignored? Is that right?
Hi @feanil, sorry for the delay getting back, I was tied up with other tasks. To clarify your question, if someone has AUTH_TOKENS.get("DEFAULT_FILE_STORAGE") Which is then used to populate: STORAGES["default"]["BACKEND"] So the config flow looks like:
Therefore, those values will not be ignored, they’re still explicitly read and mapped to the new However, outside of this pattern, will now be ignored Do you think we should shift even the Looking forward to your thoughts! |
Thanks Ram, no I think that's great, not breaking existing config but updating the internal structure to be what Django 5.2 needs makes sense to me. |
Awesome! I’ll update the PR shortly. |
Sandbox deployment failed 💥 |
@awais786 sure thing, I’m already working on that. Thank you for pointing it out. |
10bb02b
to
9881c95
Compare
Sandbox deployment failed 💥 |
8139962
to
d2ba473
Compare
Sandbox deployment failed 💥 |
Sandbox deployment failed 💥 |
Sandbox deployment failed 💥 |
d2ba473
to
3fae860
Compare
Sandbox deployment failed 💥 |
Description
This PR refactors the code to replace the deprecated
DEFAULT_FILE_STORAGE
andSTATICFILES_STORAGE
settings with the more flexible and recommendedSTORAGES = {}
pattern.Key changes:
DEFAULT_FILE_STORAGE
with the newSTORAGES['default']
setting.STATICFILES_STORAGE
with the newSTORAGES['staticfiles']
setting.Settings Flow Diagram
To better illustrate how the settings flow between files and the changes made, I've created a diagram outlining the relationship between the key settings. Below is a visual representation of the flow:

Tests Performed
pytest: Ran tests across multiple modules, including
lms
,cms
,openedx
,common
, andxmodule
. No errors related to settings were encountered.File Upload/Download:
Manage.py Commands:
Executed common Django management commands such as:
python3 manage.py lms runserver
python3 manage.py lms migrate
python3 manage.py lms print_setting STORAGES
python3 manage.py lms dump_settings
No issues or unexpected behavior were observed during command execution.
Note:
Filed an issue in
tutor-contrib-s3
to track updating the plugin forDjango 4.2+
compatibility with the newSTORAGES
setting: link to issueThis PR does not block on that, but it’s good to have this documented for future reference.