DATABASES setting for Django not being set

[dkliban]

dynaconf is properly showing the settings I put into /etc/pulp/settings.py

(pulp) [vagrant@pulp3 pulp]$ dynaconf list -k DATABASES
Django app detected
Working in development environment 
DATABASES: {'default': {'CONN_MAX_AGE': 0,
             'ENGINE': 'django.db.backends.dummy',
             'HOST': 'postgres',
             'NAME': 'pulp',
             'PORT': '5432',
             'USER': 'pulp'}}

However, django is not using the setting. It seems like Django is loading the settings for the database before dynaconf is loaded.

[rochacbruno]

Looks like Django is accessing DATABASES before the load of INSTALLED_APPS so I can think in a way to fix it.

Load dynaconf explicitly in manage.py and in wsgi.py

after this line.
https://github.com/rochacbruno/dynaconf/blob/master/example/django_example/manage.py#L6

or calling it on settings.py bottom.

[rochacbruno]

I want to add an implementation targetting Python 3.7 using this https://www.python.org/dev/peps/pep-0562/

and also I am going to try other solutions.

If we figureout that the proper way is calling dynaconf on manage.py and wsgi.py then I'll add this to the docs.

[dkliban]

Thank you! I was able to follow your advice here[0].

[0] https://github.com/pulp/pulp/pull/3678/files

[rochacbruno]

I did an extensive dive in to Django source code today,

The case is that Django is creating the database connection before it loads the INSTALLED_APPS where dynaconf is supposed to be loaded.

Django is doing that because there is a console hint saying You have N pending migrations to be applied... and to calculate that Django fires the migration check before the INSTALLED_APPS are loaded.

This is part of https://docs.djangoproject.com/en/1.11/ref/checks/#database

The only setting that Django is looking before INSTALLED_APPS is DATABASES

One of the possible solution is introducing a new environment variable for Django so users will always need to export the following 2 variables to enable Dynaconf:

export DJANGO_SETTINGS_MODULE=dynaconf.contrib.django_settings
export SETTINGS_MODULE_FOR_DYNACONF=myprogram.app.settings

Then internally the dynaconf.contrib.django_settings resolves the load of myprogram.app.settings the solution works seemlesly without the need to even change the INSTALLED APPS, the good part is that to enable dynaconf the user only needs to change envvars and no need to touch any code.

I want to hear more opinions about this idea ^.

For now I will:

• Keep this issue opened until we find a better solution (Still need to try the Django AppConfig class)
• Send an email do Django dev list asking for help/suggestions
• Include in the Dynaconf docs a note saying that:
  • "If you need the DATABASES to be rewritable please load dynaconf in manage.py, wsgi.py and any other entry point of your application intead of INSTALLED_APPS use INSTALLED_APPS only in cases where you don't need the DATABASES key to be managed by dynaconf."
• For Python 3.7 I'll include an implementation using the new module.__getattr__ method

IN all the cases, the backwards compatibility should never break! so the way you are loading dynaconf today should still work and the way using INSTALLED_APPS should also work. My plan is to introduce other ways to load it.

[mspinelli]

Any progress on this problem?

I want to hear more opinions about this idea ^.

I haven't tried the dual environment variable export yet. Are you saying this works out of the box already this way, or that it would need more code changes in dynaconf to make this work? E.g. dynaconf.contrib.django_settings doesn't seem to exist.

That said I am on Python 3.7. What does the module.__getattr__ method look like to solve this problem?

[rochacbruno]

@mspinelli the proposed solution is not implemented yet, it needs to be implemented.

Right now to use django there are 2 solutions

• 1. Load dynaconf in INSTALLED_APPS knowing that DATABASE should be kept on django's settings.
• 2. Load dynaconf in all the entry points as manage.py, wsgi.py and others.

[dmsimard]

Hi o/

By the way, I think @apollo13 had a good idea by getting dynaconf to load settings from within settings instead of patching entrypoints for this issue.

You can see the commit here: recordsansible/ara-server@fdcc003

[rochacbruno]

@dmsimard @apollo13 can we expect a Pull Request?

[apollo13]

@rochacbruno Against what? My changes just use dynaconf directly and drop the Django integration. There is not really anything to patch with that regard in dynaconf itself…

[jasisz]

I've found two more Django corner-cases.
One is ALLOWED_HOSTS - even if you change it with dynaconf, it still will have default value somewhere internally and requests will fail.
The other case is when you use settings.SOME_CONFIG in your templates - in such scenario dynaconf fails with 'Settings' object has no attribute '__name__' - this is because it goes through the django.templates.base._resolve_lookup which inspects with getcallargs on LazySettings.

[rochacbruno]

The template problem must e resolved with the recommendation to use ['key]` syntax.

The other problems there is a way to fix using getattr but only for python 3.7+

[rochacbruno]

IN progress on #126

[rochacbruno]

2.0.0 released DATABASE stuff is now fixed.
read more in https://dynaconf.readthedocs.io/en/latest/guides/django.html
example in https://github.com/rochacbruno/dynaconf/tree/master/example/django_example

@jasisz can you please test the render template? or add a reproducer on the https://github.com/rochacbruno/dynaconf/tree/master/example/django_example

Thanks!