Re: Django app custom settings testing

[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.


On Friday, January 4, 2013 4:47:57 PM UTC-5, Pedro J. Aramburu wrote:
>
> 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  > 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  wrote:
>>>
  

Re: Django app custom settings testing

[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


On Fri, Jan 4, 2013 at 12:59 PM, nkryptic  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  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)

Re: Django app custom settings testing

[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.

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  > 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 
>> > > 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
>>> .
>>> 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.
>>>
>>
>>  -- 
>> 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 
>> 

Re: Django app custom settings testing

[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


On Thu, Jan 3, 2013 at 3:37 PM, Bill Freeman  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 <
> paramb...@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.
>> 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.
>

-- 
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.

Re: Django app custom settings testing

[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

On Thu, Jan 3, 2013 at 12:05 AM, Pedro J. Aramburu
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-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.

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?

-- 
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-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.