Note: This site is currently "Under construction". I'm migrating to a new version of my site building software. Lots of things are in a state of disrepair as a result (for example, footnote links aren't working). It's all part of the process of building in public. Most things should still be readable though.

Inverting The Order Of Environmental Variables In Configs

Playing with the idea of switching the heierarchy of environments and their variables in config files. For example, I'm doing this:

Code

{
  "envars": {
    "database_host": {
      "dev": "freeside.cloud",
      "prod": "encom.cloud"
    },
    "database_name": {
      "dev": "gibson",
      "prod": "mcp"
    },
    "database_password": {
      "dev": "wintermute",
      "prod": "chess"
    },
    "database_username": {
      "dev": "william",
      "prod": "alan1"
    },
    "debug": {
      "dev": true,
      "prod": false
    },
    "log_level": {
      "dev": "INFO",
      "prod": "ERROR"
    }
  }
}

Instead of this:

Code

{
  "envs": {
    "dev": {
      "database_host": "freeside.cloud",
      "database_name": "gibson",
      "database_password": "wintermute",
      "database_username": "william",
      "debug": true,
      "log_level": "INFO"
    },
    "prod": {
      "database_host": "encom.cloud",
      "database_name": "mcp",
      "database_password": "chess",
      "database_username": "alan1",
      "debug": false,
      "log_level": "ERROR"
    }
  }
}

It's an interesting experiment. It makes things more verbose though. First, there's a lot more lines in the config itself for the same info. Then, in the code, you can't simply do `config_data = config['dev']` to get an environment loaded. Each call has to have the env defined in it. For example:

Code

config = # Load the data
env = 'dev'

print(config.database_name[env])

instead of just being able to hit it with:

Code

config = # Load the data for just 'dev'

print(config.database_name)