FLASK/DJANGO plugins ENVVAR_PREFIX must accept lowercase for consistency - Docker compose set environment variables vs .toml files

Hi all.

We are just making the jump from .env files to .toml files with Dynaconf for a Flask app. One thing that we used to do was to have a DB_URI in the .env file http://localhost:5432/mydb and another in the docker-compose file, that referenced the local db (outside the container), like http://docker.host.internal:5432/mydb. That would allow us to make migrations (flask migrate), that would use the .env set DB_URI, and also to run the docker-compose (since the env var set on the compose file would overwrite the env var set on the .env file).

Using Dynaconf, we noticed that variables are not being loaded from the compose file, it seems that the .toml files have priority, and so the compose file env vars end up being ignored. The work around is to keep changing the variables in the toml file.

I imagine this is fairly specific to our development environment (DB outside the container ecosystem), but I was wondering if this is the expected behavior. We could probably have different environments stacked on the toml files, adding a clone of the “local” environment, creating a new “docker” environment. This would probably work, but just was curious about the variables precedence logic.

Amazing lib by the way, thanks a lot for sharing! Cheers

[lowercase00]

@rochacbruno sure, my pleasure. This if my first PR in here, let me know if any other modification is needed. Also tried to improve the docs in that sense as well.

[lowercase00]

@rochacbruno I might be looking at it in a simplistic way, but I though of just adding a .upper() when getting the kwargs, both for Flask and Django. This would ensure that you could still use the current state of the app ENVVAR_PREFIX, but passing envvar_prefix would also work, since it would be converted to uppercase straight away.

# Flask Extension
# Instead of:
...
self.kwargs = kwargs

# The new way would be:
self.kwargs = {k.upper(): v for k, v in kwargs.items()}

# Django Extension
# Instead of:
...
    # 1) Create the lazy settings object reusing settings_module consts
    options = {
        k: v
        for k, v in django_settings_module.__dict__.items()
        if k.isupper()
    }

# The new way would be:
    # 1) Create the lazy settings object reusing settings_module consts
    options = {
        k.upper(): v
        for k, v in django_settings_module.__dict__.items()
        if k.isupper()
    }

This would keep the backwards compatibility, and would also accept the lowercase variation of kwargs, adding consistency to the way the original class works. Let me know if this makes sense.

The commit on the forked version is here

Cheers