• Hi,

    I do almost the same thing, creating a local settings file that is not under version control, but I prefer not to import it, but to “append” it, with something like this in the end of settings.py:

    This way, inside local.py I can use all the settings constants defined in settings.py, and override any too.

  • Yep, that’s also a good idea, but I – personally – don’t agree with overriding constants as it decreases code readability. Defining the same “constant” in different places throughout the application can become confusing.

    PS: you can always use <pre lang=”python”> </pre> for your code.

  • Hi,
    settings.py doesn’t have to be file. Django is a python application and settings is a module. You can create a settings directory with a __init__.py file in it. There you could separate the configurations in multiple files. In general I use the following files:

    • environment – specific to deployed server
    • django_app – specific to django (like MIDDLEWARE_CLASSES… )
    • logger – hooks up the logging system from python
    • application_name – application specific settings

    Don’t forget to add from import * in the __init__ file.

    I have in a configs directory the configurations for different environments. The deployment script knows what to copy to each server.
    You can apply this approach with directories for modules to views.py, urls.py or models.py files.
    I don’t say that this method is the best but it works for me.

  • Nice one. But you’re right, in the end, it matters more what works for you.

Advertisment ad adsense adlogger