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.