I'm hitting the problem reported in ticket #4436.  This ticket is currently
closed as wontfix.

I'm ok with using the --settings option to override this.  However, I do
question the decision to close the ticket, for two reasons.  First, the
settings option is not immediately obvious because this problem prevents the
"help" subcommand from even working:

$ export DJANGO_SETTINGS_MODULE=apps.myapp.settings
$ ./manage.py help
Traceback (most recent call last):
  File "./manage.py", line 11, in ?
    execute_manager(settings)
  File
"/usr/lib/python2.4/site-packages/django/core/management/__init__.py", line
301, in execute_manager
    utility.execute()
  File
"/usr/lib/python2.4/site-packages/django/core/management/__init__.py", line
238, in execute
    sys.stderr.write(self.main_help_text() + '\n')
  File
"/usr/lib/python2.4/site-packages/django/core/management/__init__.py", line
188, in main_help_text
    commands = get_commands(self.user_commands,
self.project_directory).keys()
  File
"/usr/lib/python2.4/site-packages/django/core/management/__init__.py", line
86, in get_commands
    for app_name in settings.INSTALLED_APPS:
  File "/usr/lib/python2.4/site-packages/django/conf/__init__.py", line 28,
in __getattr__
    self._import_settings()
  File "/usr/lib/python2.4/site-packages/django/conf/__init__.py", line 59,
in _import_settings
    self._target = Settings(settings_module)
  File "/usr/lib/python2.4/site-packages/django/conf/__init__.py", line 94,
in __init__
    raise ImportError, "Could not import settings '%s' (Is it on sys.path?
Does it have syntax errors?): %s" % (self.SETTINGS_MODULE, e)
ImportError: Could not import settings 'myapp.settings' (Is it on sys.path?
Does it have syntax errors?): No module named settings

Worse, it looks like the --settings option has been retired since this
ticket was closed.  I see that --settings works on an SVN extract I did
sometime back in February or so (although it is not documented on running
"manage.py help"), but it does not work on the current level:

$ ./manage.py --settings=apps.myapp.settings
Unknown command: '--settings=apps.myapp.settings'
Type 'manage.py help' for usage.
$ ./manage.py --settings apps.myapp.settings
Unknown command: '--settings'
Type 'manage.py help' for usage.

I think this warrants reopening ticket 4436.  Either we should reintroduce
--settings, make sure that the "help" option runs without first importing
settings, and describe the use of --settings in the help output; or else we
should allow DJANGO_SETTINGS_MODULE from the environment to either override
the computed value, or perhaps be reverted to as a fallback case.

Is it ok if I reopen this ticket?  I'd like to get some feedback first
rather than doing it unilaterally. :)  Thanks,

  -- Scott

--
http://scott.andstuff.org/ | http://truthadorned.org/

Ok, a few more details.  Looks like --settings does work, as long as you
specify a command (so, "./manage.py help --settings=apps.myapp.settings").
But still, there's a chicken-and-egg problem in that help itself doesn't
work if I don't specify --settings and also help doesn't report the
availability of the --settings option; seems like a globally applicable
option like that does belong on the main help display.

Just some thoughts.  It is working for me now to specify --settings in
combination with a command (silly me), but it certainly was a long road from
start to finish to arrive at the solution. :)  I do still believe that
reopening the ticket would be a good idea,

  -- Scott

#4436 documents the design decision that --settings overrides the
environment. ./manage.py has an implied --settings option, so
./manage.py by itself will ignore the environment.

The issue you're describing here is that misconfigured settings can
prevent you from seeing the very help message that would tell you what
is going wrong. This is a legitimate fault, so it should be documented
separately.

Yours,
Russ Magee %-)