[bug] @reverse_lazy doesn't get evaluated without settings.using_env

[wgordon17]

[bug] @reverse_lazy doesn't get evaluated without settings.using_env

[wgordon17]

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!

[wgordon17]

There appears to be a similarly related timing bug, I can't use a lazily evaluated value inside of @pytest.mark.parametrize

@pytest.mark.parametrize(
    ("expected_url"),
    [settings.LOGIN_URL)],
)
def test_url(expected_url):
    assert expected_url == "/admin/login/"

[pedro-psb]

Hey, thanks for the investigation and the reproduction, I'll try to have a look into this.

[pedro-psb]

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:

1. instantiate DjangoDynaconf: register hook that loads @reverse_lazy
2. execute_loader: here we load default, user settings etc
   1. 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).
3. 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.