Opened 18 months ago

Closed 17 months ago

Last modified 17 months ago

#22071 closed Cleanup/optimization (fixed)

Documentation for override_settings needs to explain how code can access overridden settings

Reported by: EvilDMP Owned by: henkvos
Component: Documentation Version: master
Severity: Normal Keywords: afraid-to-commit
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description

https://docs.djangoproject.com/en/dev/topics/testing/tools/#overriding-settings

If you are writing tests for your own code, and you need to apply override_settings, and your own code makes use of settings, you need to be careful how you import the settings.

This won't work:

from django.conf import settings

SOME_SETTING = settings.SOME_SETTING

def some_func():
    ... code that does something with SOME_SETTING

because SOME_SETTING will be set just once, at load time, and override_settings won't touch it.

Instead, you will need to refer to settings.SOME_SETTING in your code in order to get hold of the overridden setting:

from django.conf import settings

def some_func():
    ... code that does something with settings.SOME_SETTING

This should be made clear in the documentation for override_settings.

(There's a wider issue, in that it's a very common pattern to have a module in an application that gets settings from settings.py if they're available, and provides sensible defaults if they're not, so the rest of the application can be guaranteed of finding usable settings there:

django.conf import settings

SOME_SETTING = getattr(settings, "SOME_SETTING", "some default value")

Settings accessed in this way can't be overridden with override_settings, which means that an useful Django feature and a well-used Django pattern are incompatible with each other.)

Change History (6)

comment:1 Changed 18 months ago by timo

  • Triage Stage changed from Unreviewed to Accepted
  • Type changed from Uncategorized to Cleanup/optimization

It's more of a Python concept, but a sentence about this would be helpful. How about: "Avoid aliasing your settings as module-level constants as override_settings() won't work on such values since they are only evaluated the first time the module is imported."

comment:2 Changed 17 months ago by anonymous

  • Owner changed from nobody to anonymous
  • Status changed from new to assigned

comment:3 Changed 17 months ago by anonymous

  • Owner anonymous deleted
  • Status changed from assigned to new

comment:4 Changed 17 months ago by henkvos

  • Owner set to henkvos
  • Status changed from new to assigned

comment:5 Changed 17 months ago by Tim Graham <timograham@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

In e65c0ccac0741b793ba7be96f9dcc148bf26ca7d:

Fixed #22071 -- Added a warning regarding override_settings and aliasing.

Thanks EvilDMP for the suggestion.

comment:6 Changed 17 months ago by Tim Graham <timograham@…>

In 985d0865a3cfb5850f926dfd9742fa7a9ca88bdc:

[1.6.x] Fixed #22071 -- Added a warning regarding override_settings and aliasing.

Thanks EvilDMP for the suggestion.

Backport of e65c0ccac0 from master

Note: See TracTickets for help on using tickets.
Back to Top