Silently ignores --settings

[dpoirier]

Passing --settings to manage.py is supposed to override the settings package, but a project created using funfactory ignores --settings and only looks at DJANGO_SETTINGS_MODULE.

[peterbe]

That is strange. In fact, it's regression because it used to work. I'll take a look.

[peterbe]

I remember looking at this in the past and it bugged me.

However, you can do this: ./manage.py shell --settings=mysettings and it will load mysettings.py lastly. This is the same as doing DJANGO_SETTINGS_MODULE=mysettings ./manage.py shell by the way.

Whichever way you're doing it, I think it my load the default directory called "projectname.settings" once and then later load in "mysettings" which is annoying. This means that if you have the following in projectname/settings/local.py:

FOO = 'foo'
BAR = 'bar'
#BAZ not in mysettings.py

and then you have the following in projectname/settings/local.py:

FOO = "I'm in local.py"
BAZ = 'baz'

and lastly you do this:

./manage.py shell --settings=mysettings
>>> from django.conf import settings
>>> settings.FOO
'foo'
>>> settings.BAR
'bar'
>>> settings.BAZ
'baz'

Basically, it mixes the settings but takes those of mysettings.py last.

I think this is one of the hairy parts of Django that it's not proud of. However, I don't think there's a tonne we can do about it.

What is the problem this is causing you? Is it just that it's ugly and that it can potentially drag in unwanted defaults?

[peterbe]

I was WRONG in my analysis. If you have something in settings/local.py that you don't have in mysettings.py this happens:

./manage.py shell --settings=mysettings
>>> from django.conf import settings
>>> settings.BAZ
Traceback (most recent call last):
...
AttributeError: 'Settings' object has no attribute 'BAZ'

In other words, I think what happens is that projectname/settings/__init__.py is imported and executed by python when you boot up but it doesn't matter because none of its stuff gets set in django.conf.settings.

Nasty but the reality.

Can we close this issue now?

[dpoirier]

At this point, I'm not so much concerned about what ends up in django.conf.settings as what the side effects might be of importing settings modules that the user isn't expecting to be imported. That code could do anything, so it might matter after all.

[peterbe]

It could do nasty things such as setting things in os.environ or cause execution of things that affect some other state. However, I don't think it's big enough of a problem myself for messing around with the manage.py. Others might disagree. After all, if you do too crazy things in your regular settings file other than just defining variables you have a much bigger problem than being unable to use --settings=.