I’m trying to create a directory structure for a Django application that adheres to Heroku’s recommended structure as shown at the bottom of this page. As you can see, they create a “settings” directory that contains individual settings files (e.g. dev.py) that are read depending on which tier the project is being deployed to.
Now I would have expected that there would be a “settings.py” file at the same level as the settings directory that would import from one of the settings files in the settings directory. However, their graph doesn’t show any such “settings.py” file, just the directory. How are they executing the appropriate settings file without a top-level settings.py file?
Just as an experiment, I created a settings.py file that sits at the same level as the settings directory. The problem is that when I do “runserver,” the init.py file in the settings directory causes an error: “‘Settings’ object has no ‘ROOT_URLCONF'” I’m guess there is some sort of name collision because if I change the name of the settings directory to “conf” I don’t get this error.
Could the Heroku folks be assuming that the user is setting DJANGO_SETTINGS_MODULE somewhere? If not, how are they reading the correct settings file?
Thanks.
When python is import module called
settingsit looks for either a file calledsettings.pyor a directory (python module) that is calledsettingsand contains__init__.pyin it. This is just how python module system works.From there, you can decide which settings file to import inside your init file, importing stuff from insides like
prodordev. I guess that should be explained on that page somewhere, but I didn’t find it at a glance.As for Heroku, it doesn’t assume anything and goes by with django defaults. So the module
settingsis being imported.Also, I will not argue against using dev/prod settings inside your project repo, but heroku gives you a really nice way to change config on the fly using ENV variables. You can find out more on their (very good) django tutorial.