Deploying a Rum application

Stand-alone mode

We’ve already seen how we can do this in the Configure Rum to create an interface for your model section of the tutorial.

The basic steps are:

• Initialize a rum.RumApp instance
• (optionally) wrap it with deployment middleware
• Feed the resulting app to a WSGI server.

PasteDeploy can be used to do this easily since Rum implements a paste.app_factory entry point. A sample paste deploy configuration file:

[DEFAULT]
debug = true

[server:main]
use = egg:Paste#http
host = 127.0.0.1
port = 5000

[app:main]
use = egg:rum
full_stack = True
config = %(here)s/development.cfg

The development.cfg file it refers to, which configures rum.RumApp in the same way as a config dictionary would, is this one:

[DEFAULT]
debug = True

[rum.repositoryfactory]
use = 'sqlalchemy'
# These will be imported. Notation is package.subpackage.module:class
models = ['model:Person', 'model:Genre', 'model:Actor', 'model:Director', 'model:Movie', 'model:Rental']
sqlalchemy.url = 'sqlite:///movie.db'
session.transactional = True

[rum.viewfactory]
use = 'toscawidgets'

Notice that the configuration passed in this file mirrors the one we used in the Configure Rum to create an interface for your model section of the tutorial.

Embedded mode

Rum applications are self-contained, they store no state outside the graph of objects reachable from rum.RumApp so several Rum applications can coexist in the same process each of them configured in a different way.

One of the things this design enables is to run Rum inside another framework that suports delegating the response process from a controller to another WSGI app. AFAIK, Pylons (and by extension, TurboGears 2) is the only popular Python web-framework that supports this.

Why would we want to do this?

• Because we can share a common auth/authz framework to provide services to both the hosting app and Rum.
• Because the hosting app could mangle the response returned by Rum and theme it with something like Deliverance
• Because we can access information stored in the HTTP session of the underlying application.
• Generally speaking: because we can use the hosting framework’s services inside controllers/views/repositories we write ourselves. In fact, since Pylons/TG2s/Rum’s controllers are all WSGI apps, we can even plug a Pylons/TG2 controller into Rum with a little bit of adaptation code at __call__() and it will work since the context needed by TG2/Pylons controllers is still there.

Running Rum inside TurboGears 2

TODO: Write this

Running Rum inside Pylons

TODO: Write this