Django app custom settings testing

[Pedro J. Aramburu]

Hi, I'm having troubles using the override_settings decorator. The thing is I'm writing an app that has it's own settings and I'm doing it with the approach of putting a settings.py file on the app folder with something like this:

from django.conf import settings

from django.core.exceptions import ImproperlyConfigured

SETTING_A = getattr(settings, 'APP_SETTING_A', False)

SETTING_B = getattr(settings, 'APP_SETTING_B', False)

if SETTING_A and not SETTING_B:

    raise ImproperlyConfigured('"SETTING_A" is set to True but "SETTING_B" is missing.')

-----

Where SETTING_B should be a tuple that depends on SETTING_A (I know I didn't type check yet). Then I use the settings importing app.settings. The thing is, I believe, that the settings are loaded once and as they're outside the project settings.py, override settings doesn't have any effect.

What would you recommend?

[Bill Freeman]

This approach is only useful for modules that import app.settings and use things that it defines.  It doesn't affect things that import settings from django.conf .

Your app can import settings from app, and get your settings.  That's not going to affect any other app.  If you want to affect what other apps see, you must either put the settings in the main settings file, or modify django.conf.settings itself.  This last is fraught with peril, since you can't reliably control the order in which you modify the settings object versus when other modules may use its values in a persistent way.

Or am I missing your point?

Bill

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/22xrwU84AG8J.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

[Pedro J. Aramburu]

No, you're not, but, there isn't a way to load or inject the app settings so that diffsettings and other project level things (like testing) can see them? That's my question. I've read something on a github repo but it seems clunky and over-done. My main goal really is to change some settings on the tests so I can test different scenarios.

Right now it seems I can do it by manually changing the "constants" importing app.settings, saving the old values, assigning new values and restoring at the end. But, as the settings.py is loaded once, the "validation" is also done once (the ImproperlyConfigured part).

Now, my new question: If I do an object Settings or something like that, and set the __getattr__ to "dinamically" get the settings of the project settings and if it's not there default to a setting of the same object, then I should be able to change the settings with "@override_settings(SETTING_A=True)" or "with self.settings(SETTING_A=True):".

And, for example, on the explicit case of SETTING_B that depends on SETTING_A, I could override it's getter (and setter maybe) so I could raise the exceptions if needed. The thing is, I know __get__ descriptor has "priority" over "__getattr__" but on the same class (or object). If i use the @property decorator I will still have "precedence" over getattr? Since I'm applying it's __get__ descriptor to an object inside.

Just want to know if my approach would work. As I see it, it's like lazy loading the settings so if the settings change in the project environment, they should also change in the app. Or something like that is what I'm trying to do.

What do you think? What would you do?

Thank you.

--

Tres42

Pedro J. Aramburu

[nkryptic]

The only thing I've seen which handles all the cases you mention is http://passingcuriosity.com/2010/default-settings-for-django-applications/ . That may also be what you were referring to about seeing something on github.  

As to your new question, I think that would work, because every time you need the value you'd be doing a fresh lookup.  That said, it's not ideal because every time you need the value you'd be doing a fresh lookup.

[Pedro J. Aramburu]

Thanks very much and, yes, that code is what I've found. In your personal opinion, would you use a setup like that (http://passingcuriosity.com/2010/default-settings-for-django-applications/) for default settings? or is it a little bit over the top for small apps?

I think I'll try my approach for testing purposes because I really don't need diffsettings, only the test suite "compatibility". The other way that people seem to do it is using getattr(settings, 'SETTING_X', default value) every time they need the setting but it seems to violate the DRY principle and then you don't have a centralized place for the settings.

The last thing I can think of is "updating" the approach and caching the values only when it's not in testing environment, but, how do you tell? I thought looking for DEBUG=True but then I remembered the testing environment set it to False to resemble the production environment. And, lastly, would it be worth the overhead of logic for caching a few settings?

Sorry about being so "dense" with this. It's just that I'm a newbie and trying to understand the best practices so if I Open Source the app it won't be a piece of sh... Sorry again, I got carried away.

--

Tres42

Pedro J. Aramburu

To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/ell3wY2sQsAJ.

[nkryptic]

I think you're finding out that there are many different approaches to reusable app configuration, but all have their trade-offs.

I think there is also some middle ground between always checking for the value and loading it initially, and that's to be able to reload.  In your app's settings file, you could do:

from django.conf import settings

def load_settings():

    g = globals()

    g['SETTING_X'] = getattr(settings, 'SETTING_X', 5)

load_settings()

Then, when testing and using override_settings, you can just call the load_settings function to get the changed values.  You can do the same thing with your Settings class - cache the values, but allow for reloading.

I personally use the standard SETTING_X = getattr(settings, 'APP_SETTING_X', False) in a config.py file.  Then, testing is the only place where this is a problem, so I just use a mocking library to override the app settings when needed (per test or per suite).  Of course, it would be nice to have override_settings() work for my settings too, but that's the trade-off.