Opened 7 years ago

Closed 7 years ago

#3687 closed (fixed)

django.template needs settings already configured at import time

Reported by: johan.tibell@… Owned by: adrian
Component: Template system Version: 0.95
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


The import:

from django.conf import settings


EnvironmentError: Environment variable DJANGO_SETTINGS_MODULE is undefined.

Which makes it impossible to use settings.configure() which as described under stand-alone mode.

Expected behaviour: It should be possible to use settings.configure() instead of DJANGO_SETTINGS_MODULE.

Attachments (0)

Change History (6)

comment:1 Changed 7 years ago by mtredinnick

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Can you provide a few more details on how you are triggering this error, please? I cannot repeat it; I can happily import django.conf.settings without seeing this error. My test is

.-(malcolm@counterweight 20:05:28) ~
`--> python
Python 2.4.3 (#1, Oct 23 2006, 14:19:45)
[GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from django.conf import settings

Does that work for you?

You will see the error if you try to do absolutely anything with settings before calling configure(), but a simple import before using it should work.

comment:2 Changed 7 years ago by johan.tibell@…

Apparently it was the template import that broke it.

>>> from django.conf import settings
>>> from django import template
EnvironmentError: Environment variable DJANGO_SETTINGS_MODULE is undefined.

Interleaving a configure() call fixed it:

>>> from django.conf import settings
>>> settings.configure(TEMPLATE_DIRS=('/home/username/templates'))
>>> from django import template

The docs could be a bit more explicit about what "using" code before calling configure() means. Calling code in the middle of imports is a bit unintuitive (and ugly, at least to me).

comment:3 Changed 7 years ago by mtredinnick

Hmmm. That's a little unexpected. I thought that used to work.

For anybody looking at this...

There are some places where an import forces a setting to be accessed, but they shouldn't be very common. We have moved a lot of settings accesses out of default arguments in functions for just that reason. For example, have a lok at how we set up the default arguments in django.templates.loaders.filesystem.get_template_sources() -- we ensure settings is not accessed at import time. Ideally, imports should be safe from accessing settings, but executing any code at all means all bets are off.

In the interim, the workaround in Johan's previous comment is required.

comment:4 Changed 7 years ago by mtredinnick

  • Triage Stage changed from Unreviewed to Accepted

comment:5 Changed 7 years ago by mtredinnick

  • Summary changed from django.conf.settings reads DJANGO_SETTINGS_MODULE at import time to django.template needs settings already configured at import time

Changing the title to reflect the real problem.

comment:6 Changed 7 years ago by mtredinnick

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

(In [4905]) Delayed the reading of settings.USE_I18N until the first use of the i18n
functions. This solves a few import problems we are seeing. Fixed #3687. Refs #2920.

Add Comment

Modify Ticket

Change Properties
<Author field>
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.