You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
To be honest, it's not entirely clear to me where the bug is, or how I'm hitting it. But I was able to reproduce this with #1086. It appears that the custom converted (added with add_converter for reverse_lazy) doesn't end up getting evaluated until after a with settings.using_env() gets applied.
So, the tests, evaluating self.assertEqual(settings.LOGIN_URL, "/admin/login/"), works at the bottom of the test (after running with settings.using_env(), but if it's tested at the top of the test (before any with settings.using_env() statements) it fails.
I really don't know why this is, but I'm seeing the same behavior in my own repo (which is what prompted me to start digging).
Environment (please complete the following information):
OS: macos Sonoma 14.4.1
Dynaconf Version: 3.2.5 and on master
Frameworks in use: Django==3.2.25 (running in other repo) and Django==5.0.3 (running in master here)
The text was updated successfully, but these errors were encountered:
There is something in this PR, #951, that introduced this change in behavior. Using my nifty new tool, git bisect that I picked up from Django, it's definitely pinpointed to that PR as the introduction in change in behavior. I'm open to any suggestions!
I have a theory.
Just some context, the #951 PR adds a post-load hook function is used there because we can't import reverse_lazy on the top_module in settings.py. But here is what I think is happening:
instantiate DjangoDynaconf: register hook that loads @reverse_lazy
execute_loader: here we load default, user settings etc
When LOGIN_URL is loaded, its interpreted as a string, because the @reverse_lazy was not added yet (the hook is a "post" hook, its executed after loading).
post-hook is called, which then effectively registers the @reverse_lazy function, but it doesn't take effect unless we do load the setting again.
Then, if somehow we make dynaconf re-execute the loaders, the @reverse_lazy will take effect because it will be present on loading time. The with_env context calls the settings reloading, but other reloads, such as using settings.get("LOGIN_URL", fresh=True) has the same effect (it also "fixes" the problem).
My first thought for approaching this is implementing a pre-hook and calling it before the loaders execution.
Describe the bug
To be honest, it's not entirely clear to me where the bug is, or how I'm hitting it. But I was able to reproduce this with #1086. It appears that the custom converted (added with
add_converter
forreverse_lazy
) doesn't end up getting evaluated until after awith settings.using_env()
gets applied.So, the tests, evaluating
self.assertEqual(settings.LOGIN_URL, "/admin/login/")
, works at the bottom of the test (after runningwith settings.using_env()
, but if it's tested at the top of the test (before anywith settings.using_env()
statements) it fails.I really don't know why this is, but I'm seeing the same behavior in my own repo (which is what prompted me to start digging).
Environment (please complete the following information):
master
master
here)The text was updated successfully, but these errors were encountered: