manage.py imports settings.py even when --settings is used

[Artem Skoretskiy]

manage.py file has an option to use settings file you need:

./manage.py runserver --settings=mycustomsettings

But it refuses running if settings file is not present:

Error: Can't find the file 'settings.py' in the directory containing './manage.py'. It appears you've customized things.
You'll have to run django-admin.py, passing it your settings module.
(If the file settings.py does indeed exist, it's causing an ImportError somehow.)

settings.py file should not be mandatory in that case!

I have a monkey-patch for manage.py file:

#!/usr/bin/env python

# HACK BEGIN
import sys
from optparse import OptionParser, make_option
settings_module = OptionParser(option_list=[make_option('--settings')]).parse_args(sys.argv[:])[0].settings
# HACK END

from django.core.management import execute_manager

if not settings_module:                     # HACK
    try:
        import settings # Assumed to be in the same directory.
    except ImportError:
        import sys
        sys.stderr.write("Error: Can't find the file 'settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__)
        sys.exit(1)
else:                                       # HACK
    settings = __import__(settings_module)  # HACK

if __name__ == "__main__":
    execute_manager(settings)

[Russell Keith-Magee]

Agreed that this is a bit of a wart. It's also a case where we should be checking that the module exists, rather than importing and catching the import error.

[Ramiro Morales]

Replying to russellm:

... we should be checking that the module exists, rather than importing and catching the import error.

This behavior was changed in r15522. See also #10696.

[Graham King]

Try behaving like django-admin, only output error if that doesn't work. Also changed tests.

[Graham King]

If settings.py is not found, instead of issuing a warning message asking the user to run django-admin, couldn't we just do it for them? Only issue the error if that doesn't work.

The attached patch tries management.execute_from_command_line() before it issues the warning message.

That seems to make manage.py work for the three cases:

• settings.py in current directory
• settings on command line as --settings (and settings.py in current directory is optional)
• settings in env variable DJANGO_SETTINGS_MODULE (and settings.py in current directory is optional)

A disadvantage is that if no settings.py is present in the current directory, and the settings file used throws an ImportError, the actual error is obscured by the warning message. However that message asks you to try django-admin.py, which does correctly display the error.

[Ramiro Morales]

Replying to graham_king:

A disadvantage is that if no settings.py is present in the current directory, and the settings file used throws an ImportError, the actual error is obscured by the warning message. However that message asks you to try django-admin.py, which does correctly display the error.

Another nit about the proposed patch is the one shown by the test in line 870 of the admin_script tests and the change you had to make to the expected manage.py output: If no settings.py file is present in the directory and the user doesn't specify one (either with the --setting option or by the DJANGO_SETTINGS_MODULE envvar) then the error shown is (e.g. in the test case) Unknown command: 'noargs_command'. No hint is given to the user about the fact that she is trying to run manage.py without a settings file at all it the reason of the failure.

[Graham King]

Asking about which way to proceed here: ​http://groups.google.com/group/django-developers/browse_thread/thread/7a56b452ec671943

[Jacob]

Milestone 1.4 deleted

[Claude Paroz]

This is now solved with the new manage.py version introduced in r16964.