Opened 6 years ago

Closed 4 years ago

#11086 closed enhancement (wontfix)

handling different settings

Reported by: feverDream Owned by: feverDream
Priority: Medium Milestone:
Component: Metrics/Tor Weather Version:
Severity: Keywords: weather-rewrite, settings
Cc: karsten, baumanno, nufuk Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


For testing Weather locally, a few changes need to made to the django-settings for it to behave well. There seems to two ways of handling multiple settings (development, testing and production)[1] and they are described below:

  1. Settings module -> This helps in clearly separating different settings for differed phases of development but it seems like a overkill for Weather. Moreover, Karsten suggested that changes made here should affect current Weather when its deployed.
  1. Create a local-setting file -> the file will house all the custom settings for testing, but it won't be
    version controlled.

Let me know what you guys think.


Child Tickets

Change History (9)

comment:1 Changed 6 years ago by feverDream

Owner: set to feverDream
Status: newassigned

comment:2 Changed 6 years ago by feverDream


Any changes made to the weather rep shouldn't break weather when its deployed.

comment:3 Changed 6 years ago by karsten

How about we make the default settings file for development/testing and add comments what parts need to be changed for production? After all, there will be a couple testing instances but only a single production instance. That settings file will be version-controlled, but will have to be modified locally on the server.

Unless that's a bad idea for some reason?

comment:4 Changed 6 years ago by feverDream

I think there is way to choose different settings files by checking for an environment variable ( if DEV import from settings_dev ), but I haven't looked at it.

Right now, I maintain a separate file that isn't version controlled, it overrides a couple of settings that we talked about ( disable emails, add testing flags) [1]

In the meantime, I will take a look at the "environment varaibles" approach.


comment:5 Changed 6 years ago by feverDream

Here is a branch with the changes. Let me know what you think.

Last edited 6 years ago by feverDream (previous) (diff)

comment:6 Changed 6 years ago by feverDream

Summary: handing different settingshandling different settings

comment:7 Changed 6 years ago by karsten

What about my suggestion above to "make the default settings file for development/testing and add comments what parts need to be changed for production?" That means just a single file that works out of the box for testing and needs modification for production. After all, the settings file needs to be modified anyway for the SECRET_KEY.

With regard to emails, the file would contain something like (untested!):

# By default, send outgoing mail to a file for testing mode. Comment out to use local SMTP server for production mode.
EMAIL_BACKEND = 'django.core.mail.backends.filebased.EmailBackend'
EMAIL_FILE_PATH = 'weather.mail'

comment:8 Changed 6 years ago by feverDream


Here is a link to branch[1] which addresses the issue, here are the changes:

  1. Single settings file, with Testing specific settings which can be commented out
  2. Commented out some redundant stem code in config/

Let me know if you have any issues.


comment:9 Changed 4 years ago by karsten

Resolution: wontfix
Status: assignedclosed

Tor Weather has been discontinued as of May 24, 2016: Batch-closing all remaining tickets as announced in #19382. A list of these tickets and any other Weather tickets modified after June 26, 2016 will be available here:^Metrics%2FTor+Weather

Note: See TracTickets for help on using tickets.