CP 2.2 Applications and Configuration

So what best practices should one follow when planning for the configuration of a redistributable CherryPy 2.2 application? That’s not a rhetorical question. ;-) I’m hoping to get a bit of brain dumping here from those of you in the CP community that will hopefully make its way into some official documentation.

In 2.2, there is new support for mounting applications at various points on the CP object tree.

import cherrypy
from myblog import App, blog_config

cherrypy.tree.mount(App(), '/blog', blog_config)

App, of course, is our main application class. /blog is the point that we want to mount the application at. Finally, blog_config is a dictionary of app specific configuration values or an INI-style config file.

Configuration

The problem I see with this setup is that values from blog_config are not available to App at its initialization point. That means only config information that is required per-request is useful to have in blog_config. Any configuration I need at initialization time can’t be stored in the CP config file for App.

So what are my options? Here are a few I can think of:

  • Additional config file required by App(use ConfigParser)
  • Pass config info to App’s constructor
  • Require deployer to put an [app] section in their main CP config file

Did I miss anything?

The reason I am bringing this up is because I am trying to package Brockman, my Python project catalog application. In a sample start_brockman.py script, I did the following (which I guess is yet another way to handle configuration):

cherrypy.config.update(file='/path/to/brockman.conf', baseurl='/brockman')
cherrypy.tree.mount(brockman.app(), '/brockman')

Thinking of someone deploying my application (c’mon, a guy can dream, right ;-) ), I want to have as simple and robust a way as possible for configuration to happen.

So what are some thoughts?

cw

2 Responses to “CP 2.2 Applications and Configuration”

  1. Robert Brewer Says:

    The technique you used in start_brockman is how I do it myself–config.update first, then mount. This also allows me to chain config files; I actually call config.update 4 times ;) and then call mount.

  2. christian Says:

    Cool. Thanks for the response.

Leave a Reply