Ticket #356 (defect)

In the beginning, the "server.environment" config value was proposed as a means of enabling a set of features with a single config entry. For example, by setting "server.environment" to "development", the user would instantly gain the benefits of the logDebugInfoFilter, autoreload, and tracebacks in the browser, to name a few.

In practice (as this concept has been implemented in code), each such feature has required an override; that is, each "development mode" feature needed a way to be turned off, selectively, without changing the entire mode. In every case so far (except one which should probably be corrected), the override has been implemented via an additional config entry. For example:

defaultOn = (cherrypy.config.get('server.environment') == 'development')
if cherrypy.config.get('server.showTracebacks', defaultOn):
    show_tracebacks()

It is reasonable to assume that every future use of server.environment will have the same override requirements, and will be implemented in the same fashion. Therefore, it would be worth the effort to formalize this relationship between the environment mode and the config map.

One obvious way to do that would be to add a global "environments" dict to the config module. Each key would be a legal value for "server.environment", and each value would be another dict of config defaults. For example, the current 2.1-final environments would be represented as follows:

# cherrypy/config.py

environments = {
    "production": {},
    "staging": {},
    "development": {
        "autoreload.on": True,
        "server.showTracebacks": True,
        "logDebugInfoFilter.on": True,
        "server.logFileNotFound": True,
    },
}

Application developers would then be empowered to do three things: first, conveniently inspect all effects for a given environment; second, alter the builtin environments on a global scale; and third, create new environments per application as needed.

In addition, the environment-logic currently littered throughout the code would be cleaned up and centralized within config.py. Although this might be viewed as distancing code from its effects, that is desirable in this case--CherryPy code should be written without knowledge of the current environment, being content to switch based on config values only.