Name Last Update
logs Loading commit data...
sessions Loading commit data...
src Loading commit data...
.gitignore Loading commit data...
README.md Loading commit data...
Serve.py Loading commit data...
site.config.example Loading commit data...

This application operates under the assumption of the following directory structure:

-- work_dir
 |-- html (this directory, named whatever you want)
   |-- Serve.py (run this to start the CherryPy web application
   |-- src (source for the CherryPy framework additions)
   |-- README.md (this file)
 |-- site.config (config file for application, includes [apps] section)
 |-- MyModule (code that does the work)

As a convention, MyModule contains an 'apps' directory/submodule which defines an application interface. For example, if MyModule is structured like this:

-- MyModule
 |-- apps
   |-- cherrypy
     |-- root.py
     |-- __init__.py
   |-- cli
     |-- cliapp.py
     |-- __init__.py

Then I can do this:

from MyModule.apps.cherrypy import Root

because MyModule/apps/cherrypy/init.py contains the following line:

from .root import Root

... Which makes imports look nice.

The takeaway of all this is Serve.py and site.config. In site.config we create a section that looks like this:

[apps]
Root = MyModule.apps.cherrypy

And Serve.py iterates the 'apps' config dict and essentially does a dynamic import that is equivalent to:

from MyModule.apps.cherrypy import Root
cherrypy.tree.mount(Root(), config='site.config')

Finally, the benefit to all of this is that you can write your CherryPy application completely isolated from the CherryPy framework, which exists in its own repository, while keeping your module decoupled from the CherryPy framework and in ITS own repo.

Super convenient.