-
Notifications
You must be signed in to change notification settings - Fork 115
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
[PULP-210] Update deprecated django storage config #6058
[PULP-210] Update deprecated django storage config #6058
Conversation
ba1fb1a
to
fb6f05d
Compare
3890c05
to
e9be44c
Compare
6aa2681
to
94f262b
Compare
storages._backends = settings.STORAGES.copy() | ||
storages.backends |
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.
Is this the "magic" to prevent django storages to see both items we set before?
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.
No, Django in fact has both set in their default global_settings
.
But the previous hack caused a sife-effect on a specific point of django startup where it tries to get those values with a method that can't see the patch we made. The storages is a cached property, so it would hold the wrong value forever.
Line 518 does exactly what they do here.
Line 519 triggers the value to be cached.
All this magic is to give users a larger time span to upgrade.
setattr(global_settings, "DEFAULT_FILE_STORAGE", _DEFAULT_FILE_STORAGE) | ||
setattr(global_settings, "STORAGES", _STORAGES) |
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.
Setting them both here seems to contradict that they are, as you say, "mutually exclusive".
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.
The "global setting" settings is the only place where django won't complain about exclusivity. It will perform this check on a different context.
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.
Sounds weird, but I'll take your word that it works.
CHANGES/plugin_api/5404.removal
Outdated
@@ -0,0 +1 @@ | |||
Removed `DEFAULT_FILE_STORAGE` setting in favour of the new `STORAGES` options introduced in Django 4.2. |
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.
If I understand, this is a hard breaking change for plugins with storage specific code, right?
Or can plugins still "see" the old setting alongside the new one?
Also we want users to migrate to the new setting (sooner than later). You should add a second changelog for that.
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 message is not very accurate, forget to update it.
What I'm really doing is (1) updating codebase to use STORAGES + (2) allowing users to use either of both. I guess it can be two entries, with the second one stressing that now users should start migrating.
Django copies the value of DEFAULT_FILE_STORAGE to STORAGES, but not the other way around.
So yes, plugins should use STORAGES internally (I overlooked that fact).
94f262b
to
6be238c
Compare
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.
Just nitpicking on the changelogs...
CHANGES/plugin_api/5404.removal
Outdated
Started using `STORAGES` internally instead of `DEFAULT_FILE_STORAGE` and `STATICFILES_STORAGE`, | ||
which was deprecated in Django 4.2. | ||
|
||
For compatibility, plugins should replace access to: |
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.
For compatibility, plugins should replace access to: | |
For compatibility, plugins must replace access to: |
Use strong words where appropriate...
CHANGES/5404.feature
Outdated
These legacy settings were deprecated in Django 4.2 and will be removed in Pulp 3.85 or Pulp 4, | ||
whichever comes first. |
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.
These legacy settings were deprecated in Django 4.2 and will be removed in Pulp 3.85 or Pulp 4, | |
whichever comes first. | |
These legacy settings were deprecated in Django 4.2 and will be removed in Pulp 3.85. |
I appreciate the effort to get the pulp 4 idea out, but i think that part is implicit and my drag the attention away from what is important here.
Or put another way. I think we can at any time in the future claim that pulp 3.(70+n*15) will actually be pulp 4 and it will inherit the deprecations naturally.
6be238c
to
5a4dcc0
Compare
@@ -11,7 +11,6 @@ | |||
|
|||
from pulpcore.tests.functional.utils import get_files_in_manifest, download_file | |||
|
|||
from pulpcore.app import 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.
Oh dear, this test was mixing both "imports"...?
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.
Yes, it was
pulpcore/app/apps.py
Outdated
# Workaround for getting the up-to-date settings instance. | ||
# A module-level settings import is a cached version from before dynaconf do its work. | ||
from django.conf import settings | ||
|
||
self.settings = 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.
Is this part of the deprecation compatibility layer?
If so, please mark it accordingly so we know when to remove again.
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.
Yes, will do
347da3b
to
1dc0342
Compare
Django deprecated the use of DEFAULT_FILE_STORAGES and STATICFILES_STORAGE in v4.2 and removed it in v5.0. It provides a compat layer in 4.2, so even if the user set this value using the legacy key, the value will be available in django.conf.settings as: * settings.STORAGES['default']['BACKEND'] # default storage * settings.STORAGES['staticfiles']['BACKEND'] # staticfiles storage This commit updates the codebase to use the new value.
1b6b66a
to
c34c168
Compare
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.
Feel free to merge.
I was just wondering if the user facing changelog should be moved to the decprecations section (It includes a deprecation for 3.85).
I'll do that. I didnt want to use |
If you look, the title for ".removal" will be "Deprecations and Removals". |
Co-authored-by: Matthias Dellweg <2500@gmx.de>
c34c168
to
d771a25
Compare
Summary
The setting DEFAULT_FILE_STORAGE / STATCIFILES_STORAGE was deprecated in django 4.2. They've implemented a compatibility layer to enable this legacy setting to be mapped to the new STORAGES, so users could gradually move and Pulp codebase to update to using only STORAGES.
The problem is that Pulp overrides the default (using the legacy setting name), so users can't really use STORAGE, as it raises a django exceptions on mutual exclusion.
This PR does:
Open questions:
Plugins TODO
app/apps.py
) uses a module-level settings. That could cause errors, so it needs to be moved inside the AppConfig classCloses #5404