Formalize server.environment as a set of config defaults

Robert Brewer avatarRobert Brewer created an issue

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.

Comments (3)

  1. Robert Brewer

    Fixed in [761]. Note that each entry in the new config.environment dict must list ''all'' configs which are affected by ''any'' environment, so that an environment on a child path can override an environment on a parent path.

  2. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.