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.
On Thursday, January 3, 2013 4:10:37 PM UTC-5, Pedro J. Aramburu wrote:
>
> 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
>
>
> On Thu, Jan 3, 2013 at 3:37 PM, Bill Freeman <ke1...@gmail.com<javascript:>
> > wrote:
>
>> 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
>>
>>
>> On Thu, Jan 3, 2013 at 12:05 AM, Pedro J. Aramburu
>> <para...@tres42.com.ar<javascript:>
>> > wrote:
>>
>>> 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?
>>>
>>> --
>>> 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<javascript:>
>>> .
>>> To unsubscribe from this group, send email to
>>> django-users...@googlegroups.com <javascript:>.
>>> For more options, visit this group at
>>> http://groups.google.com/group/django-users?hl=en.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To post to this group, send email to django...@googlegroups.com<javascript:>
>> .
>> To unsubscribe from this group, send email to
>> django-users...@googlegroups.com <javascript:>.
>> For more options, visit this group at
>> http://groups.google.com/group/django-users?hl=en.
>>
>
>
--
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/-/ell3wY2sQsAJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
