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 On Fri, Jan 4, 2013 at 12:59 PM, nkryptic <nkryp...@gmail.com> wrote: > 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> 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> 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<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<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. >>> 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<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. > -- You received this message because you are subscribed to the Google Groups "Django users" group. 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.
